[jira] [Commented] (OFBIZ-7346) connection pooling not working

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-7346:
--

We have this patched in our dev environment, will be pushed to live next month 
if we have no issues. So there's a good chance we'll find any problems

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Critical
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7346) connection pooling not working

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-7346:
--

I think most db drivers set autoCommit = true on new connections. You set it to 
false to begin a transaction, call commit/rollback and then potentially reset 
autoCommit to previous value. OFBiz does not do this as it uses transaction 
manager which does it implicitly. I think both the transaction manager and dbcp 
reset autoCommit. I had to download sourcecode for both geronimo and dbcp to 
figure it out.

I suspect if you set autoCommit in OFBiz, it may not work or may 
commit/rollback current transaction if already in one

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Critical
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6386:
--

Jacopo beat me to it!

> compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
> compare certain values correctly
> -
>
> Key: OFBIZ-6386
> URL: https://issues.apache.org/jira/browse/OFBIZ-6386
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Mridul Pathak
>Priority: Minor
> Attachments: compareBigDecimals.png, v1.patch, v2.patch
>
>
> Moving the conversation from OFBIZ-6291 to this issue.
> compareBigDecimals scales down and rounds up meaning you lose information and 
> the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6386:
--

{quote}
Mini-language is a scripting language. One of the nice things about scripting 
languages is you can compare things like decimal values without worrying about 
the underlying implementation. That is what the current implementation does: 2 
== 2.0 == 2.00.
{quote}

is not quite true in the my opinion. In minilang, field type conversion and 
comparison defaults to string representation unless you explicitly define the 
type, string comparison and numerical comparison are different. When it comes 
to comparing BigDecimals, information is lost (ie scale is changed, lowered) so 
values that are not the same can be interpreted to be the same (check attached 
image). Example, 2.01 == 2.001 when using  compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
> compare certain values correctly
> -
>
> Key: OFBIZ-6386
> URL: https://issues.apache.org/jira/browse/OFBIZ-6386
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Mridul Pathak
>Priority: Minor
> Attachments: compareBigDecimals.png, v1.patch, v2.patch
>
>
> Moving the conversation from OFBIZ-6291 to this issue.
> compareBigDecimals scales down and rounds up meaning you lose information and 
> the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7346) connection pooling not working

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-7346:
--

setRollbackOnReturn fixed the actual issue, when a connection is returned to 
the pool, dbcp will call rollback and an error is thrown because the connection 
has already been committed (this is database driver throwing the error). It 
calls rollback because of an issue with the cached state of autoCommit in dbcp 
as noted in the description

setEnableAutoCommitOnReturn I believe is not required and may not have any 
affect. But I observed autoCommit was being set to true at transaction commit 
(can't remember source file/line) so setting it again when returning to the 
pool is redundant

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Critical
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-7344) db connections remain open and unused on startup

[Gareth Carter (JIRA)]

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

Gareth Carter edited comment on OFBIZ-7344 at 6/15/16 11:13 AM:


I tested again. Without the patch, the connections stayed idle even after a 
long period of time (~1 hour). With the patch, these disappear after ~10 mins. 
It may not be obvious that the connections stay idle and not reused after 
startup. But different environments could cause different behaviours. 

Atleast the patch fixes bad practice (not closing resources after use!)

Also, I would note I only noticed this issue because running the query 'select 
* from pg_stat_activity' showed idle connections established days before and 
query_start roughly the same as backend_start.

But anyway, thanks Jacques for committing and for testing as well


was (Author: gareth.carter):
I tested again. Without the patch, the connections stayed idle even after a 
long period of time (~1 hour). With the patch, these disappear after ~10 mins. 
It may not be obvious that the connections stay idle and not reused after 
startup. But different environments could cause different behaviours. 

Atleast the patch fixes bad practice (not closing resources after use!)

Also, I would note I only noticed this issue because running the query 'select 
* from pg_stat_activity' showed idle connections established days before and 
query_start roughly the same as backend_start.

> db connections remain open and unused on startup
> 
>
> Key: OFBIZ-7344
> URL: https://issues.apache.org/jira/browse/OFBIZ-7344
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: DatabaseUtil.patch
>
>
> When ofbiz starts and checks the database, it will leave open connections and 
> will not get reused.
> If you run Check/Update database from webtools, you can see a new connection 
> is created for your selected group
> As far as I can tell, the problem lies in DatabaseUtil.getDatabaseMetaData. 
> If the parameter connection is null, a new connection object is created but 
> not closed (like any resource should be!)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7344) db connections remain open and unused on startup

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-7344:
--

I tested again. Without the patch, the connections stayed idle even after a 
long period of time (~1 hour). With the patch, these disappear after ~10 mins. 
It may not be obvious that the connections stay idle and not reused after 
startup. But different environments could cause different behaviours. 

Atleast the patch fixes bad practice (not closing resources after use!)

Also, I would note I only noticed this issue because running the query 'select 
* from pg_stat_activity' showed idle connections established days before and 
query_start roughly the same as backend_start.

> db connections remain open and unused on startup
> 
>
> Key: OFBIZ-7344
> URL: https://issues.apache.org/jira/browse/OFBIZ-7344
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: DatabaseUtil.patch
>
>
> When ofbiz starts and checks the database, it will leave open connections and 
> will not get reused.
> If you run Check/Update database from webtools, you can see a new connection 
> is created for your selected group
> As far as I can tell, the problem lies in DatabaseUtil.getDatabaseMetaData. 
> If the parameter connection is null, a new connection object is created but 
> not closed (like any resource should be!)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7346) connection pooling not working

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-7346:
-
Attachment: DBCPConnectionFactory.patch

Here is a patch we have put on our trunk server which seems to work but unsure 
of implications if any

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7346) connection pooling not working

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-7346:
-
Description: 
Connection pooling does not seem to work. Connections are created fine but as 
the close() method is called (outside of transaction) or the transaction is 
committed the connections are closed to the db server and not returned to the 
pool.

I believe the issue is with org.apache.commons.dbcp2.PoolableConnectionFactory 
passivateObject method. This will call rollback() when rollbackOnReturn is set 
to true even if the transaction is committed. This is because any connection 
wrappers extending org.apache.commons.dbcp2.DelegatingConnection cache 
autoCommit status. At some point, this cached autoCommit is different from the 
underlying connection autoCommit. The rollback() method will throw an exception 
and the connection is destroyed rather than put back to the pool

Environment this has been tested on:
ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
db: postgresql 9.1
jdbc driver: postgresql-9.3-1101.jdbc4
os: linux and windows

I have asked dev ml for others to check this with other dbs. Jacques has test 
with postgres but could not see this behaviour

  was:
Connection pooling does not seem to work. Connections are created fine but as 
the close() method is called (outside of transaction) or the transaction is 
committed the connections are closed to the db server and not returned to the 
pool.

I believe the issue is with org.apache.commons.dbcp2.PoolableConnectionFactory 
passivateObject method. This will call rollback() when rollbackOnReturn is set 
to true even if the transaction is committed. This is because any connection 
wrappers extending org.apache.commons.dbcp2.DelegatingConnection cache 
autoCommit status. At some point, this cached autoCommit is different from the 
underlying connection autoCommit. The rollback() method will throw an exception 
and the connection is destroyed rather than put back to the pool


> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Minor
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7346) connection pooling not working

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-7346:


 Summary: connection pooling not working
 Key: OFBIZ-7346
 URL: https://issues.apache.org/jira/browse/OFBIZ-7346
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor


Connection pooling does not seem to work. Connections are created fine but as 
the close() method is called (outside of transaction) or the transaction is 
committed the connections are closed to the db server and not returned to the 
pool.

I believe the issue is with org.apache.commons.dbcp2.PoolableConnectionFactory 
passivateObject method. This will call rollback() when rollbackOnReturn is set 
to true even if the transaction is committed. This is because any connection 
wrappers extending org.apache.commons.dbcp2.DelegatingConnection cache 
autoCommit status. At some point, this cached autoCommit is different from the 
underlying connection autoCommit. The rollback() method will throw an exception 
and the connection is destroyed rather than put back to the pool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7344) db connections remain open and unused on startup

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-7344:
-
Attachment: DatabaseUtil.patch

This patch removes the need for getDatabaseMetaData to create a connection. I 
have created 2 new methods to retrieve the information from DatabaseMetaData 
and close connections as required.

My initial patch closed the connection after retrieving the database meta data 
but this may cause issues later if connection is flagged as closed

> db connections remain open and unused on startup
> 
>
> Key: OFBIZ-7344
> URL: https://issues.apache.org/jira/browse/OFBIZ-7344
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: DatabaseUtil.patch
>
>
> When ofbiz starts and checks the database, it will leave open connections and 
> will not get reused.
> If you run Check/Update database from webtools, you can see a new connection 
> is created for your selected group
> As far as I can tell, the problem lies in DatabaseUtil.getDatabaseMetaData. 
> If the parameter connection is null, a new connection object is created but 
> not closed (like any resource should be!)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7344) db connections remain open and unused on startup

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-7344:


 Summary: db connections remain open and unused on startup
 Key: OFBIZ-7344
 URL: https://issues.apache.org/jira/browse/OFBIZ-7344
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor


When ofbiz starts and checks the database, it will leave open connections and 
will not get reused.

If you run Check/Update database from webtools, you can see a new connection is 
created for your selected group

As far as I can tell, the problem lies in DatabaseUtil.getDatabaseMetaData. If 
the parameter connection is null, a new connection object is created but not 
closed (like any resource should be!)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-3847:
--

When I highlighted the line, I meant that oldValue is null not parameter value 
is null. 

I have just tested it again, value is not null but it is a GenericPK so it has 
no references all non pk fields

Here is a stack trace from eclipse

Daemon Thread [ajp-bio-8019-exec-3] (Suspended (breakpoint at line 137 in 
EntityEcaRule))   
owns: SocketWrapper  (id=194)
EntityEcaRule.eval(String, DispatchContext, GenericEntity, boolean, 
Set) line: 137  
DelegatorEcaHandler.evalRules(String, Map, 
String, GenericEntity, boolean) line: 109
GenericDelegator$EntityEcaRuleRunner.evalRules(String, String, 
GenericEntity, boolean) line: 2274
GenericDelegator.removeByPrimaryKey(GenericPK) line: 1004   
GenericWebEvent.updateGeneric(HttpServletRequest, HttpServletResponse) 
line: 158
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not 
available [native method]  
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43  
Method.invoke(Object, Object...) line: 498  
JavaEventHandler.invoke(String, String, Class, Class[], Object[]) 
line: 92
JavaEventHandler.invoke(ConfigXMLReader$Event, 
ConfigXMLReader$RequestMap, HttpServletRequest, HttpServletResponse) line: 78   
 
RequestHandler.runEvent(HttpServletRequest, HttpServletResponse, 
ConfigXMLReader$Event, ConfigXMLReader$RequestMap, String) line: 759   
RequestHandler.doRequest(HttpServletRequest, HttpServletResponse, 
String, GenericValue, Delegator) line: 476
ControlServlet.doGet(HttpServletRequest, HttpServletResponse) line: 213 
ControlServlet(HttpServlet).service(HttpServletRequest, 
HttpServletResponse) line: 620  
ControlServlet(HttpServlet).service(ServletRequest, ServletResponse) 
line: 727  
ApplicationFilterChain.internalDoFilter(ServletRequest, 
ServletResponse) line: 303  
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 
208  
ContextFilter.doFilter(ServletRequest, ServletResponse, FilterChain) 
line: 323  
ApplicationFilterChain.internalDoFilter(ServletRequest, 
ServletResponse) line: 241  
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 
208  
StandardWrapperValve.invoke(Request, Response) line: 220
StandardContextValve.invoke(Request, Response) line: 122
NonLoginAuthenticator(AuthenticatorBase).invoke(Request, Response) 
line: 505
StandardHostValve.invoke(Request, Response) line: 170   
ErrorReportValve.invoke(Request, Response) line: 103
StandardEngineValve.invoke(Request, Response) line: 116 
AccessLogValve.invoke(Request, Response) line: 956  
CoyoteAdapter.service(Request, Response) line: 423  
AjpProcessor.process(SocketWrapper) line: 190   

AjpProtocol$AjpConnectionHandler(AbstractProtocol$AbstractConnectionHandler).process(SocketWrapper,
 SocketStatus) line: 625 
JIoEndpoint$SocketProcessor.run() line: 316 

ThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) 
line: 1142  
ThreadPoolExecutor$Worker.run() line: 617   
TaskThread$WrappingRunnable.run() line: 61  
TaskThread(Thread).run() line: 745  


> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
> Fix For: Upcoming Branch
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store 

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-3847:
--

Hi Paul

Thanks for the quick response!

My guess is the field (availableToPromiseDiff in InventoryItemDetail example) 
is available in the value parameter but the field value is null.

InventoryItemDetail is a bad example here but we had to remove some records 
because of invalid data. We could not do this via webtools but could using 
pgadmin.

As for a fix, all I can think of is either check for null on oldValue or don't 
run the check on remove operation. This will eliminate NPE and 
setLastInventoryCount would not run though I am not sure if this would be 
correct behaviour if availableToPromiseDiff = null?


> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
> Fix For: Upcoming Branch
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-3847:
--

Hi

I have just encountered an issue caused by the patch committed for this issue.

If you delete records in an entity that has an eca on operation="remove" and 
conditions on the eca, you receive a NPE because of the line highlighted
{code:title=org.ofbiz.entityext.eca.EntityEcaRule}
if( !fieldsToLoad.isEmpty()) {
Delegator delegator = dctx.getDelegator();
--> GenericValue oldValue =  delegator.findOne(entityName, 
value.getPrimaryKey(), false); // null on remove
for( String fieldName : fieldsToLoad) {
value.put(fieldName, oldValue.get(fieldName));
}
}
{code}

The old value does not exist any more and is null.


An example eca:


{code:title=applications/product/entitydef/eecas.xml}




{code}

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5732) Error in sendMailHiddenInLog service

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5732:
--

I would, we've applied this as a patch in our production systems now and works 
fine. 

> Error in sendMailHiddenInLog service
> 
>
> Key: OFBIZ-5732
> URL: https://issues.apache.org/jira/browse/OFBIZ-5732
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>
> I got the following error when calling sendMailHiddenInLog, see the errors 
> below.
> {code}
> 2014-08-27 02:18:41,395 (OFBiz-JobQueue-0) [  
> ServiceDispatcher.java:550:ERROR]
>  exception report 
> --
> Could not commit transaction for service [sendMailHiddenInLog] call
> Exception: org.ofbiz.entity.transaction.GenericTransactionException
> Message: Roll back error, could not commit transaction, was rolled back 
> instead because of: Service [sendMailMultiPart] threw an unexpected 
> exception/errororg.ofbiz.service.ServiceValidationException: The following 
> required parameter is missing: [IN] [sendMailMultiPart.bodyParts] (The 
> following required parameter is missing: [IN] [sendMailMultiPart.bodyParts])
>  cause 
> -
> Exception: org.ofbiz.service.ServiceValidationException
> Message: The following required parameter is missing: [IN] 
> [sendMailMultiPart.bodyParts]
>  stack trace 
> ---
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
> org.ofbiz.service.ModelService.validate(ModelService.java:630)
> org.ofbiz.service.ModelService.validate(ModelService.java:572)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:381)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.common.email.EmailServices.sendFailureNotification(EmailServices.java:667)
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:349)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69)
> org.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> 
> {code}
> I think we should miss the code below before line 667 in EmailServices.java
> {code}
> newContext.put("bodyParts", bodyParts);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6686) The following required parameter is missing: [IN] [sendMailMultiPart.bodyParts] (The following required parameter is missing: [IN] [sendMailMultiPart.bodyParts])

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6686:
--

I believe this is an issue with sendFailureNotification - see OFBIZ-5732 for 
details

> The following required parameter is missing: [IN] 
> [sendMailMultiPart.bodyParts] (The following required parameter is missing: 
> [IN] [sendMailMultiPart.bodyParts])
> -
>
> Key: OFBIZ-6686
> URL: https://issues.apache.org/jira/browse/OFBIZ-6686
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: Release Branch 13.07
>Reporter: Derek Lew
>
> Hi 
> in WorkEffort --> Calendar, create an event.  the following exception is 
> thrown.
> 2015-10-20 11:57:09,910 |OFBiz-JobQueue-1 |ModelService  
> |E| [ModelService.validate] : {sendMailMultiPart} : (IN) Required test error: 
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
> 2015-10-20 11:57:09,910 |OFBiz-JobQueue-1 |ServiceDispatcher 
> |E| Incoming context (in runSync : sendMailMultiPart) does not match expected 
> requirements
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
>   at org.ofbiz.service.ModelService.validate(ModelService.java:642) 
> ~[ofbiz-service.jar:?]
>   at org.ofbiz.service.ModelService.validate(ModelService.java:578) 
> ~[ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:381) 
> [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232) 
> [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.common.email.EmailServices.sendFailureNotification(EmailServices.java:664)
>  [ofbiz-common.jar:?]
>   at 
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:346) 
> [ofbiz-common.jar:?]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_40]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_40]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_40]
>   at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_40]
>   at 
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400) 
> [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232) 
> [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.common.email.EmailServices.sendMailFromScreen(EmailServices.java:591)
>  [ofbiz-common.jar:?]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_40]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_40]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_40]
>   at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_40]
>   at 
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400) 
> [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232) 
> [ofbiz-service.jar:?]
>   at 
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:98)
>  [ofbiz-service.jar:?]
>   at 
> org.ofbiz.minilang.method.callops.CallService.exec(CallService.java:217) 
> [ofbiz-minilang.jar:?]
>   at org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:307) 
> [ofbiz-minilang.jar:?]
>   at org.ofbiz.minilang.method.ifops.IfNotEmpty.exec(IfNotEmpty.java:61) 
> [ofbiz-minilang.jar:?]
>   at org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:307) 
> [ofbiz-minilang.jar:?]
>   at 

[jira] [Commented] (OFBIZ-5732) Error in sendMailHiddenInLog service

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5732:
--

Also I think OFBiz-6686 is related. A report of a similar error but others are 
not able to reproduce - I believe the user put in the wrong email address and 
is calling this service sendFailureNotification

> Error in sendMailHiddenInLog service
> 
>
> Key: OFBIZ-5732
> URL: https://issues.apache.org/jira/browse/OFBIZ-5732
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>
> I got the following error when calling sendMailHiddenInLog, see the errors 
> below.
> {quote}
> 2014-08-27 02:18:41,395 (OFBiz-JobQueue-0) [  
> ServiceDispatcher.java:550:ERROR]
>  exception report 
> --
> Could not commit transaction for service [sendMailHiddenInLog] call
> Exception: org.ofbiz.entity.transaction.GenericTransactionException
> Message: Roll back error, could not commit transaction, was rolled back 
> instead because of: Service [sendMailMultiPart] threw an unexpected 
> exception/errororg.ofbiz.service.ServiceValidationException: The following 
> required parameter is missing: [IN] [sendMailMultiPart.bodyParts] (The 
> following required parameter is missing: [IN] [sendMailMultiPart.bodyParts])
>  cause 
> -
> Exception: org.ofbiz.service.ServiceValidationException
> Message: The following required parameter is missing: [IN] 
> [sendMailMultiPart.bodyParts]
>  stack trace 
> ---
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
> org.ofbiz.service.ModelService.validate(ModelService.java:630)
> org.ofbiz.service.ModelService.validate(ModelService.java:572)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:381)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.common.email.EmailServices.sendFailureNotification(EmailServices.java:667)
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:349)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69)
> org.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> 
> {quote}
> I think we should miss the code below before line 667 in EmailServices.java
> {code:title=|borderStyle=solid}
> newContext.put("bodyParts", bodyParts);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5732) Error in sendMailHiddenInLog service

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5732:
--

We've just encountered this problem. Testing with the suggested fix...

> Error in sendMailHiddenInLog service
> 
>
> Key: OFBIZ-5732
> URL: https://issues.apache.org/jira/browse/OFBIZ-5732
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Wei Zhang
>
> I got the following error when calling sendMailHiddenInLog, see the errors 
> below.
> {quote}
> 2014-08-27 02:18:41,395 (OFBiz-JobQueue-0) [  
> ServiceDispatcher.java:550:ERROR]
>  exception report 
> --
> Could not commit transaction for service [sendMailHiddenInLog] call
> Exception: org.ofbiz.entity.transaction.GenericTransactionException
> Message: Roll back error, could not commit transaction, was rolled back 
> instead because of: Service [sendMailMultiPart] threw an unexpected 
> exception/errororg.ofbiz.service.ServiceValidationException: The following 
> required parameter is missing: [IN] [sendMailMultiPart.bodyParts] (The 
> following required parameter is missing: [IN] [sendMailMultiPart.bodyParts])
>  cause 
> -
> Exception: org.ofbiz.service.ServiceValidationException
> Message: The following required parameter is missing: [IN] 
> [sendMailMultiPart.bodyParts]
>  stack trace 
> ---
> org.ofbiz.service.ServiceValidationException: The following required 
> parameter is missing: [IN] [sendMailMultiPart.bodyParts]
> org.ofbiz.service.ModelService.validate(ModelService.java:630)
> org.ofbiz.service.ModelService.validate(ModelService.java:572)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:381)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.common.email.EmailServices.sendFailureNotification(EmailServices.java:667)
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:349)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:606)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:100)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:57)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:400)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:232)
> org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:83)
> org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69)
> org.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> java.lang.Thread.run(Thread.java:745)
> 
> {quote}
> I think we should miss the code below before line 667 in EmailServices.java
> {code:title=|borderStyle=solid}
> newContext.put("bodyParts", bodyParts);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

Yes, we should change it for consistency

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6705.patch, OFBIZ-6705.patch, 
> OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

Sorry Jacques but this Jira hasn't actually been fixed, the files noted in 
description field still use 1 for viewIndex however your commit will make it 
easier to fix. We should make them consistent with the rest of ofbiz, please 
reopen this jira and I will assign it to myself and create a patch

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6705.patch, OFBIZ-6705.patch, 
> OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

His views are reasonable and we were in a similar scenario (using java8 on 
ubuntu 12:04 but we have just upgraded to oracle jdk and running fine). However 
you can't run ofbiz trunk without java 8 unless you change build.xml, I am 
unsure if this applies to any of the latest releases?

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-6705.patch, OFBIZ-6705.patch, 
> OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6985) New Theme sponsored by Provolve and Stannah

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6985:
--

I have submitted my ICLA today

> New Theme sponsored by Provolve and Stannah
> ---
>
> Key: OFBIZ-6985
> URL: https://issues.apache.org/jira/browse/OFBIZ-6985
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Upcoming Branch
>Reporter: Hans Bakker
>Priority: Minor
>
> This theme was created by a big ofbiz customer and contributed to the the 
> ofbiz community.
> A demo you can see in GrowERP:
> https://minimum.growerpdemo.com/backend/control/main?PASSWORD=ofbiz=admin



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

Thanks for reviewing, please provide any suggestions. 

Are we planning to include any java 8 features now? It might be worth adding 
lambda expression to EntityQuery such as forEach method

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-6705.patch, OFBIZ-6705.patch, 
> OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6705:
-
Attachment: OFBIZ-6705.patch

patch with some javadoc

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: OFBIZ-6705.patch, OFBIZ-6705.patch, 
> OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

Yes I can add javadoc, I initially didn't add so the community can review, if 
it needs to be changed it's less work for ;)

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: OFBIZ-6705.patch, OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6705:
-
Attachment: OFBIZ-6705_sample.patch

Here is a sample of using it.

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: OFBIZ-6705.patch, OFBIZ-6705_sample.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6705:
-
Attachment: OFBIZ-6705.patch

OFBIZ-6705.patch contains suggested changes, I wasn't 100% sure where to put 
certain methods, I just went with what I felt was right. This is based on 
internal work so method names and locations don't have to be as they are in the 
patch

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: OFBIZ-6705.patch
>
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

I will provide a patch of what we have done internally (roughly the same but 
changed to be in the framework) and sample usage.

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

Its been a few months that anyone has posted on this jira, I just want to 
highlight (looking at the source files some more) that when manually paging 
through data, almost the same source lines are copied and pasted (looking at 
OrderLooupServices.java, ShowVisits.groovy and EditShoppingList.groovy but 
there could be more, much more...). 

Eg 
 - retrieving viewIndex/viewSize (setting defaults if they don't exist)
 - calculating lowIndex/highIndex
 - retrieving resultset size

It would be nice, maybe as part of the latest refactoring, to include a method 
do all this in one go?

We have implemented something like this in our internal components. We have a 
PagedList object (stores list of data items, resultset size, viewSize, 
viewIndex, lowIndex (I call it startIndex) and highIndex (called endIndex), we 
also have a utils class that returns the PagedList object based on a 
EntityListIterator, viewSize and viewIndex. We created this code before 
EntityQuery was used but it would certainly be handy to have a method on 
EntityQuery as well

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6983) Change default type for view-map to something more appropriate

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6983:


 Summary: Change default type for view-map to something more 
appropriate
 Key: OFBIZ-6983
 URL: https://issues.apache.org/jira/browse/OFBIZ-6983
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial


The default value for the 'type' attribute on a view-map entry is "default". 
There is no default view-handler and (atleast at rev 1725574) you get a stack 
overflow error. I suggest changing the default to screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6848) Add getFieldList method to EntityQuery

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6848:


 Summary: Add getFieldList method to EntityQuery
 Key: OFBIZ-6848
 URL: https://issues.apache.org/jira/browse/OFBIZ-6848
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor


Improve EntityQuery by adding method getFieldList so we don't have to chain to 
EntityUtils.getFieldListFromEntityList or getFieldListFromEntityListIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6848) Add getFieldList method to EntityQuery

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6848:
-
Attachment: EntityQuery.patch

> Add getFieldList method to EntityQuery
> --
>
> Key: OFBIZ-6848
> URL: https://issues.apache.org/jira/browse/OFBIZ-6848
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: EntityQuery.patch
>
>
> Improve EntityQuery by adding method getFieldList so we don't have to chain 
> to EntityUtils.getFieldListFromEntityList or 
> getFieldListFromEntityListIterator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6697) CommunicationServices.createAttachmentContent duplicates attachments for existing CommunicationEvents

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6697:
--

We have been using this patch in production for about 2 months now and have no 
reports of any issues. I don't personally believe it should matter about the 
method signature as it's private, should only deprecate public methods

> CommunicationServices.createAttachmentContent duplicates attachments for 
> existing CommunicationEvents
> -
>
> Key: OFBIZ-6697
> URL: https://issues.apache.org/jira/browse/OFBIZ-6697
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Nicolas Malin
>Priority: Minor
> Attachments: FixDuplicateCommEventAttachments.patch
>
>
> When sending an email from a CommunicationEvent that exists in the database 
> prior to calling sendMail/sendMailMultiPart, the seca 
> updateCommEventAfterEmail will call createAttachmentContent and store any 
> attachments into ImageDataResource and be referenced by the 
> CommunicationEvent even if the attachments already exist in the database (and 
> stored somewhere else).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Thats the thing isn't it? There is no case. For date only fields, there is not 
enough information to accurately apply different timezone formats. For all date 
fields you'd have to ensure you set ignore-time-zone="false" but I fear this 
functionality will get lost or misunderstood later down the line hence why I 
tried to apply the fix globally (in widget framework)

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, French calendar 
> tootip.png, IgnoreTimeZone.patch, ObjectTypeTests.patch, dates.patch, 
> dates_1589040.patch, en-GB calendar tootip.png, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (OFBIZ-6655) Add session tracking mode and make cookie secure

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6655:
-
Comment: was deleted

(was: FYI, most of the local DTD/schemas are found in servlet-api-3.0.jar. The 
LocalResolver in UtilXml will need to be changed or schema removed from all 
web.xml files. 

I believe tomcat OOTB uses this jar - see 
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/util/SchemaResolver.html,
 however I have not looked into it with any depth)

> Add session tracking mode and make cookie secure
> 
>
> Key: OFBIZ-6655
> URL: https://issues.apache.org/jira/browse/OFBIZ-6655
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk, 14.12.01
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Attachments: OFBIA-6655.applications.patch, 
> OFBIZ-6655.framework_themes.patch, sessionConifg_ecommerce.patch
>
>
> Need to enhance security at web-app level. 
> As per current implementation:
> - The cookie containing the session identifier is not secure
> - The session identifier is transmitted in the query string of the URL
> To fix these issue we have to add following session config otpions in web.xml
> {code}
> 
>   
>   true
>   true
>   
>   COOKIE
> 
> {code}
> Also we need to update the web-app servlet specification from 2.3 to 3.0
> {code}
>  xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> 
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> https://tomcat.apache.org/whichversion.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6655) Add session tracking mode and make cookie secure

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6655:
--

FYI, most of the local DTD/schemas are found in servlet-api-3.0.jar. The 
LocalResolver in UtilXml will need to be changed or schema removed from all 
web.xml files. 

I believe tomcat OOTB uses this jar - see 
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/util/SchemaResolver.html,
 however I have not looked into it with any depth

> Add session tracking mode and make cookie secure
> 
>
> Key: OFBIZ-6655
> URL: https://issues.apache.org/jira/browse/OFBIZ-6655
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk, 14.12.01
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Attachments: OFBIA-6655.applications.patch, 
> OFBIZ-6655.framework_themes.patch, sessionConifg_ecommerce.patch
>
>
> Need to enhance security at web-app level. 
> As per current implementation:
> - The cookie containing the session identifier is not secure
> - The session identifier is transmitted in the query string of the URL
> To fix these issue we have to add following session config otpions in web.xml
> {code}
> 
>   
>   true
>   true
>   
>   COOKIE
> 
> {code}
> Also we need to update the web-app servlet specification from 2.3 to 3.0
> {code}
>  xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> 
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> https://tomcat.apache.org/whichversion.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6655) Add session tracking mode and make cookie secure

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6655:
--

FYI, most of the local DTD/schemas are found in servlet-api-3.0.jar. The 
LocalResolver in UtilXml will need to be changed or schema removed from all 
web.xml files. 

I believe tomcat OOTB uses this jar - see 
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/util/SchemaResolver.html,
 however I have not looked into it with any depth

> Add session tracking mode and make cookie secure
> 
>
> Key: OFBIZ-6655
> URL: https://issues.apache.org/jira/browse/OFBIZ-6655
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk, 14.12.01
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Attachments: OFBIA-6655.applications.patch, 
> OFBIZ-6655.framework_themes.patch, sessionConifg_ecommerce.patch
>
>
> Need to enhance security at web-app level. 
> As per current implementation:
> - The cookie containing the session identifier is not secure
> - The session identifier is transmitted in the query string of the URL
> To fix these issue we have to add following session config otpions in web.xml
> {code}
> 
>   
>   true
>   true
>   
>   COOKIE
> 
> {code}
> Also we need to update the web-app servlet specification from 2.3 to 3.0
> {code}
>  xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> 
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> https://tomcat.apache.org/whichversion.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Actually from what I remember, we had to change the VisualThemeResource to load 
the UK datejs file, something has changed in trunk for this to happen as I am 
pretty sure datejs was loaded from browsers locale.

The only other object I would advise to handle is a string object which 
represents a date/time/date-time in ISO format only but this a matter of 
opinion. You could just leave it as java.sql.Date is the object only used to 
represent a date field throughout ofbiz (including java.sql.Time for time and 
java.sql.Timestamp for date-time)

 Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, IgnoreTimeZone.patch, 
> ObjectTypeTests.patch, dates.patch, dates_1589040.patch, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter edited comment on OFBIZ-5608 at 11/17/15 4:18 PM:


I have created a person on trunk with locale set to en-US, setting the Birth 
Date field to today (2015-11-17), the hidden field is 2015-11-17 (as expected), 
the display field shows 11/17/2015. The value is stored in the database and 
displays in the same format on screen when retrieved.

The only issue was the value stored in the database was 2015-11-16 because the 
admin timezone is set to America/New_York (the problem that this jira 
represents). Might be worth moving the discussion of formats to another jira?

**Edit

I should say it's not the America/New_York timezone that is specifically the 
problem, its the fact that America/New_York relative to the servers timezone 
applies a negative offset to java.sql.Date (its subtracting x hours from the 
date) when formatting to a string. As mentioned before java.sql.Date has no 
time component and therefore should not subtract hours or apply offsets


was (Author: gareth.carter):
I have created a person on trunk with locale set to en-US, setting the Birth 
Date field to today (2015-11-17), the hidden field is 2015-11-17 (as expected), 
the display field shows 11/17/2015. The value is stored in the database and 
displays in the same format on screen when retrieved.

The only issue was the value stored in the database was 2015-11-16 because the 
admin timezone is set to America/New_York (the problem that this jira 
represents). Might be worth moving the discussion of formats to another jira?

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, French calendar 
> tootip.png, IgnoreTimeZone.patch, ObjectTypeTests.patch, dates.patch, 
> dates_1589040.patch, en-GB calendar tootip.png, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

I have created a person on trunk with locale set to en-US, setting the Birth 
Date field to today (2015-11-17), the hidden field is 2015-11-17 (as expected), 
the display field shows 11/17/2015. The value is stored in the database and 
displays in the same format on screen when retrieved.

The only issue was the value stored in the database was 2015-11-16 because the 
admin timezone is set to America/New_York (the problem that this jira 
represents). Might be worth moving the discussion of formats to another jira?

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, French calendar 
> tootip.png, IgnoreTimeZone.patch, ObjectTypeTests.patch, dates.patch, 
> dates_1589040.patch, en-GB calendar tootip.png, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Ok I tried on trunk, it seems to be working though the formats specified by 
datejs do not correspond to the formats specified in CommonUiLabels for 
tooltips. 

Examples:
 - Germany (DE), datejs uses dd.MM. format but tooltip specifies -MM-dd 
(both are valid).
 - USA (en-US), datejs uses M/d/ where tooltip specified -MM-dd

France and British formats are the same

I have not checked others but no doubt there are some missing or wrong

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, French calendar 
> tootip.png, IgnoreTimeZone.patch, ObjectTypeTests.patch, dates.patch, 
> dates_1589040.patch, en-GB calendar tootip.png, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Yes the tooltip doesn't but what if you select a date from the picker? What 
format is the viewable input field?

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, French calendar 
> tootip.png, IgnoreTimeZone.patch, ObjectTypeTests.patch, dates.patch, 
> dates_1589040.patch, en-GB calendar tootip.png, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter edited comment on OFBIZ-5608 at 11/17/15 9:44 AM:


I was under the impression that ofbiz will always render date/time fields as 
ISO format into the hidden field and let the javascript framework handle 
internationalization of the viewable field. This can certainly lead to the 
tooltip displaying a different format from the actual input. Tooltip text is 
based on the user login locale, but the javascript is dependent on the browser 
locale.

The javascript library is datejs and you can see the formats used by the 
browser from the javascript object Date.CultureInfo


was (Author: gareth.carter):
I was under the impression that ofbiz will always render date/time fields as 
ISO format into the hidden field and let the javascript framework handle 
internationalization of the viewable field. This can certainly lead to the 
tooltip displaying a different format from the actual input. Tooltip text is 
based on the user login locale, but the javascript is dependent on the browser 
locale

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, IgnoreTimeZone.patch, 
> ObjectTypeTests.patch, dates.patch, dates_1589040.patch, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

I was under the impression that ofbiz will always render date/time fields as 
ISO format into the hidden field and let the javascript framework handle 
internationalization of the viewable field. This can certainly lead to the 
tooltip displaying a different format from the actual input. Tooltip text is 
based on the user login locale, but the javascript is dependent on the browser 
locale

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, IgnoreTimeZone.patch, 
> ObjectTypeTests.patch, dates.patch, dates_1589040.patch, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

It is expected that when  is used the displayed data 
comes from java.sql.Date but I expected the widget framework could handle other 
objects (java.sql.Timestamp, java.sql.Time, java.util.Date, maybe even 
string?). My guess is the majority of cases is java.sql.Date

It should only made true by default for date only (and maybe time only)

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
> dates.patch, dates_1589040.patch, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-6210) Replace EntityUtilProperties with EntityClassLoader

[Gareth Carter (JIRA)]

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

Gareth Carter edited comment on OFBIZ-6210 at 11/6/15 11:32 AM:


I have found a few minor issues with this implementation.

1) You can override other (internal) resources in JavaResource. Example 
"META-INF/services/javax.xml.parsers.DocumentBuilderFactory" as resourceName 
with 0 length resourceValue will prevent XML documents being read. 
2) Related to above - resource loading looks at JavaResource first then the 
parent, ClassLoader looks at parent first
3) With EntityClassLoader enabled in ControlServlet, cleariing all cache in 
webtools creates a deadlock situation causing many threads to be created 
(ForkJoinPool). Eventually an OutOfMemoryError is thrown

Here is a stacktrace for point 3 (all other threads have same stack trace)
{noformat}
"ForkJoinPool-1-worker-6869" #7112 daemon prio=5 os_prio=0 
tid=0x0001b87ed800 nid=0x8658 in Object.wait() [0x0002d805e000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.concurrent.ForkJoinTask.internalWait(ForkJoinTask.java:311)
- locked <0xf8be7328> (a 
java.util.concurrent.ForkJoinTask$AdaptedCallable)
at java.util.concurrent.ForkJoinPool.awaitJoin(ForkJoinPool.java:2058)
at java.util.concurrent.ForkJoinTask.doJoin(ForkJoinTask.java:390)
at java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1001)
at 
org.ofbiz.base.concurrent.ExecutionPool.getAllFutures(ExecutionPool.java:83)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.readConfig(EntityEcaUtil.java:104)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.getEntityEcaCache(EntityEcaUtil.java:59)
at 
org.ofbiz.entityext.eca.DelegatorEcaHandler.getEntityEventMap(DelegatorEcaHandler.java:86)
at 
org.ofbiz.entity.GenericDelegator.createEntityEcaRuleRunner(GenericDelegator.java:2205)
at 
org.ofbiz.entity.GenericDelegator.getEcaRuleRunner(GenericDelegator.java:2201)
at org.ofbiz.entity.GenericDelegator.findOne(GenericDelegator.java:1410)
at org.ofbiz.entity.GenericDelegator.findOne(GenericDelegator.java:1398)
at 
org.ofbiz.entity.util.EntityClassLoader.findResource(EntityClassLoader.java:88)
at 
org.ofbiz.entity.util.EntityClassLoader.getResource(EntityClassLoader.java:146)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1304)
at org.apache.xerces.parsers.SecuritySupport$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.xerces.parsers.SecuritySupport.getResourceAsStream(Unknown Source)
at 
org.apache.xerces.parsers.ObjectFactory.findJarServiceProvider(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
at org.ofbiz.base.util.UtilXml$1.(UtilXml.java:480)
at org.ofbiz.base.util.UtilXml.readXmlDocument(UtilXml.java:480)
at org.ofbiz.base.util.UtilXml.readXmlDocument(UtilXml.java:410)
at 
org.ofbiz.base.component.ComponentResourceHandler.getDocument(ComponentResourceHandler.java:67)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.getEcaDefinitions(EntityEcaUtil.java:131)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.access$000(EntityEcaUtil.java:48)
at org.ofbiz.entityext.eca.EntityEcaUtil$1.call(EntityEcaUtil.java:150)
at org.ofbiz.entityext.eca.EntityEcaUtil$1.call(EntityEcaUtil.java:148)
at 
java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at 
java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at 
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
{noformat}


was (Author: gareth.carter):
I have found a few minor issues with this implementation.

1) You can override other (internal) resources in JavaResource. Example 
"META-INF/services/javax.xml.parsers.DocumentBuilderFactory" as resourceName 
with 0 length resourceValue will prevent XML documents being read. 
2) Related to above - resource loading looks at JavaResource first then the 
parent, ClassLoader looks at parent first
3) With EntityClassLoader enabled in ControlServlet, cleariing all cache in 
webtools creates a deadlock situation causing many threads to be created 
(ForkJoinPool). Eventually an OutOfMemoryError is thrown

Here is a stacktrace for point 3 (all other threads have same stack 

[jira] [Commented] (OFBIZ-6210) Replace EntityUtilProperties with EntityClassLoader

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6210:
--

I have found a few minor issues with this implementation.

1) You can override other (internal) resources in JavaResource. Example 
"META-INF/services/javax.xml.parsers.DocumentBuilderFactory" as resourceName 
with 0 length resourceValue will prevent XML documents being read. 
2) Related to above - resource loading looks at JavaResource first then the 
parent, ClassLoader looks at parent first
3) With EntityClassLoader enabled in ControlServlet, cleariing all cache in 
webtools creates a deadlock situation causing many threads to be created 
(ForkJoinPool). Eventually an OutOfMemoryError is thrown

Here is a stacktrace for point 3 (all other threads have same stack trace)
"ForkJoinPool-1-worker-6869" #7112 daemon prio=5 os_prio=0 
tid=0x0001b87ed800 nid=0x8658 in Object.wait() [0x0002d805e000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.concurrent.ForkJoinTask.internalWait(ForkJoinTask.java:311)
- locked <0xf8be7328> (a 
java.util.concurrent.ForkJoinTask$AdaptedCallable)
at java.util.concurrent.ForkJoinPool.awaitJoin(ForkJoinPool.java:2058)
at java.util.concurrent.ForkJoinTask.doJoin(ForkJoinTask.java:390)
at java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1001)
at 
org.ofbiz.base.concurrent.ExecutionPool.getAllFutures(ExecutionPool.java:83)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.readConfig(EntityEcaUtil.java:104)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.getEntityEcaCache(EntityEcaUtil.java:59)
at 
org.ofbiz.entityext.eca.DelegatorEcaHandler.getEntityEventMap(DelegatorEcaHandler.java:86)
at 
org.ofbiz.entity.GenericDelegator.createEntityEcaRuleRunner(GenericDelegator.java:2205)
at 
org.ofbiz.entity.GenericDelegator.getEcaRuleRunner(GenericDelegator.java:2201)
at org.ofbiz.entity.GenericDelegator.findOne(GenericDelegator.java:1410)
at org.ofbiz.entity.GenericDelegator.findOne(GenericDelegator.java:1398)
at 
org.ofbiz.entity.util.EntityClassLoader.findResource(EntityClassLoader.java:88)
at 
org.ofbiz.entity.util.EntityClassLoader.getResource(EntityClassLoader.java:146)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1304)
at org.apache.xerces.parsers.SecuritySupport$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.xerces.parsers.SecuritySupport.getResourceAsStream(Unknown Source)
at 
org.apache.xerces.parsers.ObjectFactory.findJarServiceProvider(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
at org.apache.xerces.parsers.DOMParser.(Unknown Source)
at org.ofbiz.base.util.UtilXml$1.(UtilXml.java:480)
at org.ofbiz.base.util.UtilXml.readXmlDocument(UtilXml.java:480)
at org.ofbiz.base.util.UtilXml.readXmlDocument(UtilXml.java:410)
at 
org.ofbiz.base.component.ComponentResourceHandler.getDocument(ComponentResourceHandler.java:67)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.getEcaDefinitions(EntityEcaUtil.java:131)
at 
org.ofbiz.entityext.eca.EntityEcaUtil.access$000(EntityEcaUtil.java:48)
at org.ofbiz.entityext.eca.EntityEcaUtil$1.call(EntityEcaUtil.java:150)
at org.ofbiz.entityext.eca.EntityEcaUtil$1.call(EntityEcaUtil.java:148)
at 
java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at 
java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at 
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)


> Replace EntityUtilProperties with EntityClassLoader
> ---
>
> Key: OFBIZ-6210
> URL: https://issues.apache.org/jira/browse/OFBIZ-6210
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Adrian Crum
>Priority: Minor
>
> The EntityUtilProperties implementation is very limited and requires 
> rewriting a lot of code. Using EntityClassLoader will achieve the same result 
> without changing any code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Patch works.

To test:
- Set timezone to Europe/London
- Modify PartyForms.xml#EditPerson. Add the following to the form:
{code}



{code}
- Create a new person with birth date edited
- Change timezone to America/New_York
- Edit person and you should see birthdate is the same value when set in 
Europe/London timezone
- If you change ignore-time-zone = "false" and edit again, the birthdate field 
should contain the original date - 1 day

With the patch as it is, none of the forms with a date only field will have 
ignore-time-zone="true" set, so ofbiz will behave as it does without this 
patch. Would there be any plans to update existing forms? Eg 
PartyForms.xml#EditPerson

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Priority: Minor
> Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
> dates.patch, dates_1589040.patch, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6702:
-
Attachment: OFBIZ-6702-2.patch

See slight mod to SimpleContentViewHandler

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Trivial
> Attachments: ContentDisposition.patch, OFBIZ-6702-2.patch, 
> OFBIZ-6702.patch, SimpleContentViewHandler.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

I should mention I mean this only from SimpleContentViewHandler for downloads, 
I don't think SimpleViewContentHandler is used anywhere to render html ?

Like I said, we should force text/plain or application/octet-stream for 
text/html through SimpleContentViewHandler or even force disposition type 
attachment regardless of the property. This will ensure any 
Content/DataResource records that are html do not render as html web pages when 
accessed via SimpleContentViewHandler only

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Trivial
> Attachments: ContentDisposition.patch, OFBIZ-6702.patch, 
> SimpleContentViewHandler.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

I need to test again, OFBIZ-6537 prevented me but now that is fixed I will try

> Dates Displaying Incorrectly With Negative Offest Timezones.
> 
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Priority: Minor
> Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
> dates.patch, dates_1589040.patch, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are 
> applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

Patch seems to work.

May have found a slight security issue with this (could have been in the links 
in previous comments), if a html file is stored in DataResource, the the mime 
type would be text/html. This causes the html to be rendered as a web page 
rather than viewed as text in the browser window. My suggestion would be return 
text/plain or application/octet-stream for uploaded html files, this would 
cause either download or viewing the html contents if inline was set

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Trivial
> Attachments: ContentDisposition.patch, OFBIZ-6702.patch, 
> SimpleContentViewHandler.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

Here is an interesting link about security 
https://code.google.com/p/browsersec/wiki/Part2

https://tools.ietf.org/html/rfc6266
{quote}
On the other hand, if it matches "inline" (case-insensitively), this
   implies default processing.  Therefore, the disposition type "inline"
   is only useful when it is augmented with additional parameters, such
   as the filename (see below).
{quote}

Seems like specifying inline is the equivalent of not adding 
Content-Disposition.

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Trivial
> Attachments: ContentDisposition.patch, OFBIZ-6702.patch, 
> SimpleContentViewHandler.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6702:
-
Attachment: ContentDisposition.patch

I use the requestHandler properties file to store the default type. Not been 
tested though

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Trivial
> Attachments: ContentDisposition.patch, 
> SimpleContentViewHandler.java.patch, UtilHttp.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

I only noticed this because we have a custom service (searches orders) and on 
the custom screen we invoke 
applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy. 
This always sets viewIndex to 1 so the first page never displays.

I am not sure of the implication of setting these to 0, it could be that the 
code further on accomodates for viewIndex = 1. I am just highlighting that 
these files are inconsistent with the rest of ofbiz and (my opinion) need to be 
changed. Of course I will help and try to provide patches

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6705:
--

applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy
applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy

The above 2 just set the viewIndex in the context. FindOrders will filter to 
OrderLookupServices, don't know about ListCommunications.groovy


applications/order/src/org/ofbiz/order/order/OrderLookupServices.java
applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy
specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy

These 3 files will calculate correctly (subtracting 1 from viewIndex) to get 
the startIndex. Will have to update the code if we change viewIndex = 0

> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

Seems like firefox will honour Content-Disposition: attachment, I am sure 
others will.

If IE (or any other browser) does mime type sniffing then potentially setting 
Content-Disposition to inline may mean javascript could execute if the 
determined mime type is text/html. Ofbiz itself could sniff the mime type when 
files are uploaded. Even validated against the mime type determined by the file 
extension. 

The solution you propose is a good fit, it atleast keeps the same behaviour 
with the option to change. Might I suggest content.properties instead of 
general.properties



> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: SimpleContentViewHandler.java.patch, UtilHttp.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

I initially said content because of SimpleContentViewHandler but could webapp 
be an alternative? Since Content-Disposition only relates to http. I have no 
preference here

I have found 7 references in code (that actually set it on the 
HttpServletReponse) for Content-Disposition. It might be worth adding a new 
method to UtilHttp so the filename can be formatted correctly (it's 
inconsistent)

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: SimpleContentViewHandler.java.patch, UtilHttp.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

general.properties it is then

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: SimpleContentViewHandler.java.patch, UtilHttp.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6705:


 Summary: some files set viewIndex to 1 by default rather than 0
 Key: OFBIZ-6705
 URL: https://issues.apache.org/jira/browse/OFBIZ-6705
 Project: OFBiz
  Issue Type: Bug
Reporter: Gareth Carter
Priority: Minor


The following files set viewIndex to 1

./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:
if (viewIndex == null) viewIndex = 1;
./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
<#--assign viewIndex = viewIndex - 1/-->
./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
 = request.getParameter("viewIndex") ? 
Integer.valueOf(request.getParameter("viewIndex")) : 1;
./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
 = 1;
./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy:   
 viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);

I ran this command to get the output:
grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"

As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6705) some files set viewIndex to 1 by default rather than 0

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6705:
-
Description: 
The following files set viewIndex to 1

{noformat}
./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:
if (viewIndex == null) viewIndex = 1;
./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
<#--assign viewIndex = viewIndex - 1/-->
./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
 = request.getParameter("viewIndex") ? 
Integer.valueOf(request.getParameter("viewIndex")) : 1;
./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
 = 1;
./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy:   
 viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
{noformat}

I ran this command to get the output:
grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"

As far as I am aware, viewIndex starts from 0

  was:
The following files set viewIndex to 1

./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:
if (viewIndex == null) viewIndex = 1;
./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
<#--assign viewIndex = viewIndex - 1/-->
./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
 = request.getParameter("viewIndex") ? 
Integer.valueOf(request.getParameter("viewIndex")) : 1;
./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
 = 1;
./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy:   
 viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);

I ran this command to get the output:
grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"

As far as I am aware, viewIndex starts from 0


> some files set viewIndex to 1 by default rather than 0
> --
>
> Key: OFBIZ-6705
> URL: https://issues.apache.org/jira/browse/OFBIZ-6705
> Project: OFBiz
>  Issue Type: Bug
>Reporter: Gareth Carter
>Priority: Minor
>
> The following files set viewIndex to 1
> {noformat}
> ./applications/order/src/org/ofbiz/order/order/OrderLookupServices.java:  
>   if (viewIndex == null) viewIndex = 1;
> ./applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl:
> <#--assign viewIndex = viewIndex - 1/-->
> ./applications/order/webapp/ordermgr/WEB-INF/actions/order/FindOrders.groovy:viewIndex
>  = request.getParameter("viewIndex") ? 
> Integer.valueOf(request.getParameter("viewIndex")) : 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/communication/ListCommunications.groovy:context.viewIndex
>  = 1;
> ./applications/party/webapp/partymgr/WEB-INF/actions/visit/ShowVisits.groovy: 
>viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> ./specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/actions/shoppinglist/EditShoppingList.groovy:
> viewIndex = Integer.valueOf(parameters.VIEW_INDEX  ?: 1);
> {noformat}
> I ran this command to get the output:
> grep -R --exclude-dir=.svn "viewIndex = " . | grep " 1"
> As far as I am aware, viewIndex starts from 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6702:
--

The inline change is not super important. I just felt it was better for our 
users to be able to view images and pdfs in the browser window (rather than 
force download) and thought it might be worth committing. 

Content-Disposition could be ignored by the browser (although I doubt latest 
mainstream browsers do not) or could be overridden by browser configuration, I 
know in firefox you can configure what to do based on mime type - 
https://support.mozilla.org/en-US/kb/applications-panel-set-how-firefox-handles-files.
 I do not know if inline/attachment is honoured if a specific action set


> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: SimpleContentViewHandler.java.patch, UtilHttp.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6702:
-
Attachment: UtilHttp.java.patch
SimpleContentViewHandler.java.patch

> Update SimpleContentViewHandler to return mime type on file extension and use 
> inline for content-disposition
> 
>
> Key: OFBIZ-6702
> URL: https://issues.apache.org/jira/browse/OFBIZ-6702
> Project: OFBiz
>  Issue Type: Improvement
>  Components: content
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: SimpleContentViewHandler.java.patch, UtilHttp.java.patch
>
>
> SimpleContentViewHandler will return mime type 'text/html' for all 
> DataResource values without a specified mimeTypeId. Changing to 
> DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
> extension 
> Fixing the mime type will allow the browsers to display content inline if 
> UtilHttp is updated aswell. All unknown extensions will be set to 
> octet-stream causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6702) Update SimpleContentViewHandler to return mime type on file extension and use inline for content-disposition

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6702:


 Summary: Update SimpleContentViewHandler to return mime type on 
file extension and use inline for content-disposition
 Key: OFBIZ-6702
 URL: https://issues.apache.org/jira/browse/OFBIZ-6702
 Project: OFBiz
  Issue Type: Improvement
  Components: content
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: SimpleContentViewHandler.java.patch, UtilHttp.java.patch

SimpleContentViewHandler will return mime type 'text/html' for all DataResource 
values without a specified mimeTypeId. Changing to 
DataResourceWorker.getMimeType will allow determining the mimeTypeId by file 
extension 

Fixing the mime type will allow the browsers to display content inline if 
UtilHttp is updated aswell. All unknown extensions will be set to octet-stream 
causing the browser to prompt for download



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6697) CommunicationServices.createAttachmentContent duplicates attachments for existing CommunicationEvents

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6697:
-
Attachment: FixDuplicateCommEventAttachments.patch

> CommunicationServices.createAttachmentContent duplicates attachments for 
> existing CommunicationEvents
> -
>
> Key: OFBIZ-6697
> URL: https://issues.apache.org/jira/browse/OFBIZ-6697
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Minor
> Attachments: FixDuplicateCommEventAttachments.patch
>
>
> When sending an email from a CommunicationEvent that exists in the database 
> prior to calling sendMail/sendMailMultiPart, the seca 
> updateCommEventAfterEmail will call createAttachmentContent and store any 
> attachments into ImageDataResource and be referenced by the 
> CommunicationEvent even if the attachments already exist in the database (and 
> stored somewhere else).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6698) sendCommEventAsEmail does not filter CommEventContentAssoc

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6698:
--

Would it be worth changing to use EntityQuery rather than getRelated? 
EntityQuery provides EntityCondition date filter rather than 
EntityUtil.filterByDate

> sendCommEventAsEmail does not filter CommEventContentAssoc
> --
>
> Key: OFBIZ-6698
> URL: https://issues.apache.org/jira/browse/OFBIZ-6698
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
>
> I only found this whilst testing another piece of code. The emails that were 
> being sent contained attachments that were expired.
> It's unlikely that attachments for new CommunicationEvents will be expired in 
> the time it took to create the records and send the email but it might be 
> worth adding.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6664) Enhance theme js and css settings with caching and other parameters.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6664:
--

What about combining and minifying css/js used for all requests? I created a 
script to do but only found the number of http requests go from ~50 to < 10 
with very little rendering performance improvements

A note on cache, we attempted to use apache2 mod_cache module but seems like 
there are jsessionids attached to some of the css/js and caused us major issues 
(session hijacking) and had to stop - in fact we had to completely disable it

> Enhance theme js and css settings with caching and other parameters.
> 
>
> Key: OFBIZ-6664
> URL: https://issues.apache.org/jira/browse/OFBIZ-6664
> Project: OFBiz
>  Issue Type: Improvement
>  Components: themes
>Affects Versions: Trunk, Bootstrap theme
>Reporter: Pierre Smits
>
> In order to have fast rendering of pages multiple options are available. 
> These include cache-control and async for css and js files.
> Currently those settings can't be set when using visual theme resources. In 
> order to enhance the user experience and aiding developers we should figure 
> out a way to set those variables in the dataset(s) of themes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6621) MapContext.entrySet() slows down when ByteBuffer objects are in the context

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6621:
--

Also, we have deployed this to our live servers as our users were reporting 
major performance issues when uploading attachments. I had created a script 
that when 1min load average > 1, it would send myself an email with the java 
process stacktrace (jstack), before patch I would receive the email every 5 
mins! Since it has been applied, i have not received any emails yet (but not 
been 24 hours yet)

> MapContext.entrySet() slows down when ByteBuffer objects are in the context
> ---
>
> Key: OFBIZ-6621
> URL: https://issues.apache.org/jira/browse/OFBIZ-6621
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Critical
> Attachments: MapContext-v2.patch, MapContext.patch
>
>
> When MapContext is used anywhere (eg FlexibleStringExpander) and the context 
> contains ByteBuffer objects (either key or value), java will slow down when 
> calling MapContext.entrySet().
> Here is the code in ofbiz, highlighted is the line of code that I believe is 
> the culprit
> {code:title=MapContext.java}
> public Set> entrySet() {
> // walk the stackList and the entries for each Map and if nothing is in 
> for the current key, put it in
> Set resultKeySet = new HashSet();
> culprit --> Set> resultEntrySet = new 
> ListSet>();
> for (Map curMap: this.stackList) {
> for (Map.Entry curEntry: curMap.entrySet()) {
> if (!resultKeySet.contains(curEntry.getKey())) {
> resultKeySet.add(curEntry.getKey());
> resultEntrySet.add(curEntry);
> }
> }
> }
> return Collections.unmodifiableSet(resultEntrySet);
> }
> {code}
> Looking at the java api for Map.Entry, the hashCode method for Map.Entry is 
> the result of the hashCode from both key and value. ByteBuffer hash code is 
> dependent upon its content. If a 2mb file is uploaded, the hashCode method
> of ByteBuffer will scan 2mb to generate the hashCode
> ByteBuffer
> http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#hashCode()
> {quote}Because buffer hash codes are content-dependent, it is inadvisable to 
> use buffers as keys in hash maps or similar data structures unless it is 
> known that their contents will not change.{quote}
> Map.Entry
> http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode()
> {quote}(e.getKey()==null   ? 0 : e.getKey().hashCode()) ^ (e.getValue()==null 
> ? 0 : e.getValue().hashCode()){quote}
> HashSet
> http://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html
> {quote}This class implements the Set interface, backed by a hash table 
> (actually a HashMap instance{quote}
> Example where ByteBuffer objects are created
> {code}org.ofbiz.webapp.event.ServiceEventHandler{code}
> Example stack trace
> {noformat}
> "ajp-bio-8009-exec-1894" daemon prio=10 tid=0x7fa52c07 nid=0x5c73 
> runnable [0x7fa51151b000]
>java.lang.Thread.State: RUNNABLE
>   at java.nio.HeapByteBuffer.ix(HeapByteBuffer.java:131)
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:139)
>   at java.nio.ByteBuffer.hashCode(ByteBuffer.java:1083)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.AbstractMap.hashCode(AbstractMap.java:494)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.HashMap.hash(HashMap.java:362)
>   at java.util.HashMap.put(HashMap.java:492)
>   at java.util.HashSet.add(HashSet.java:217)
>   at 
> org.ofbiz.base.util.collections.MapContext.entrySet(MapContext.java:306)
>   at java.util.HashMap.putAll(HashMap.java:642)
>   at 
> org.ofbiz.widget.model.ModelFormField$ListOptions.addOptionValues(ModelFormField.java:2716)
>   at 
> org.ofbiz.widget.model.ModelFormField$FieldInfoWithOptions.getAllOptionValues(ModelFormField.java:1985)
>   at 
> org.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDropDownField(MacroFormRenderer.java:747)
>   at 
> org.ofbiz.widget.model.ModelFormField$DropDownField.renderFieldString(ModelFormField.java:1739)
>   at 
> org.ofbiz.widget.model.ModelFormField.renderFieldString(ModelFormField.java:693)
>   at 
> org.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(FormRenderer.java:1195)
>   at org.ofbiz.widget.renderer.FormRenderer.render(FormRenderer.java:261)
>   at 
> 

[jira] [Updated] (OFBIZ-6621) MapContext.entrySet() slows down when ByteBuffer objects are in the context

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6621:
-
Attachment: MapContext-v2.patch

New patch with ListSet as private inner class

> MapContext.entrySet() slows down when ByteBuffer objects are in the context
> ---
>
> Key: OFBIZ-6621
> URL: https://issues.apache.org/jira/browse/OFBIZ-6621
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Critical
> Attachments: MapContext-v2.patch, MapContext.patch
>
>
> When MapContext is used anywhere (eg FlexibleStringExpander) and the context 
> contains ByteBuffer objects (either key or value), java will slow down when 
> calling MapContext.entrySet().
> Here is the code in ofbiz, highlighted is the line of code that I believe is 
> the culprit
> {code:title=MapContext.java}
> public Set> entrySet() {
> // walk the stackList and the entries for each Map and if nothing is in 
> for the current key, put it in
> Set resultKeySet = new HashSet();
> culprit --> Set> resultEntrySet = new 
> ListSet>();
> for (Map curMap: this.stackList) {
> for (Map.Entry curEntry: curMap.entrySet()) {
> if (!resultKeySet.contains(curEntry.getKey())) {
> resultKeySet.add(curEntry.getKey());
> resultEntrySet.add(curEntry);
> }
> }
> }
> return Collections.unmodifiableSet(resultEntrySet);
> }
> {code}
> Looking at the java api for Map.Entry, the hashCode method for Map.Entry is 
> the result of the hashCode from both key and value. ByteBuffer hash code is 
> dependent upon its content. If a 2mb file is uploaded, the hashCode method
> of ByteBuffer will scan 2mb to generate the hashCode
> ByteBuffer
> http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#hashCode()
> {quote}Because buffer hash codes are content-dependent, it is inadvisable to 
> use buffers as keys in hash maps or similar data structures unless it is 
> known that their contents will not change.{quote}
> Map.Entry
> http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode()
> {quote}(e.getKey()==null   ? 0 : e.getKey().hashCode()) ^ (e.getValue()==null 
> ? 0 : e.getValue().hashCode()){quote}
> HashSet
> http://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html
> {quote}This class implements the Set interface, backed by a hash table 
> (actually a HashMap instance{quote}
> Example where ByteBuffer objects are created
> {code}org.ofbiz.webapp.event.ServiceEventHandler{code}
> Example stack trace
> {noformat}
> "ajp-bio-8009-exec-1894" daemon prio=10 tid=0x7fa52c07 nid=0x5c73 
> runnable [0x7fa51151b000]
>java.lang.Thread.State: RUNNABLE
>   at java.nio.HeapByteBuffer.ix(HeapByteBuffer.java:131)
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:139)
>   at java.nio.ByteBuffer.hashCode(ByteBuffer.java:1083)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.AbstractMap.hashCode(AbstractMap.java:494)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.HashMap.hash(HashMap.java:362)
>   at java.util.HashMap.put(HashMap.java:492)
>   at java.util.HashSet.add(HashSet.java:217)
>   at 
> org.ofbiz.base.util.collections.MapContext.entrySet(MapContext.java:306)
>   at java.util.HashMap.putAll(HashMap.java:642)
>   at 
> org.ofbiz.widget.model.ModelFormField$ListOptions.addOptionValues(ModelFormField.java:2716)
>   at 
> org.ofbiz.widget.model.ModelFormField$FieldInfoWithOptions.getAllOptionValues(ModelFormField.java:1985)
>   at 
> org.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDropDownField(MacroFormRenderer.java:747)
>   at 
> org.ofbiz.widget.model.ModelFormField$DropDownField.renderFieldString(ModelFormField.java:1739)
>   at 
> org.ofbiz.widget.model.ModelFormField.renderFieldString(ModelFormField.java:693)
>   at 
> org.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(FormRenderer.java:1195)
>   at org.ofbiz.widget.renderer.FormRenderer.render(FormRenderer.java:261)
>   at 
> org.ofbiz.widget.model.ModelScreenWidget$Form.renderWidgetString(ModelScreenWidget.java:1052)
>   at 
> org.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderScreenletSubWidget(MacroScreenRenderer.java:677)
>   at 
> org.ofbiz.widget.model.ModelScreenWidget$Screenlet.renderWidgetString(ModelScreenWidget.java:598)
>   at 
> 

[jira] [Created] (OFBIZ-6621) MapContext.entrySet() slows down when ByteBuffer objects are in the context

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6621:


 Summary: MapContext.entrySet() slows down when ByteBuffer objects 
are in the context
 Key: OFBIZ-6621
 URL: https://issues.apache.org/jira/browse/OFBIZ-6621
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Critical


When MapContext is used anywhere (eg FlexibleStringExpander) and the context 
contains ByteBuffer objects (either key or value), java will slow down when 
calling MapContext.entrySet().

Here is the code in ofbiz, highlighted is the line of code that I believe is 
the culprit

{code:title=MapContext.java}
public Set> entrySet() {
// walk the stackList and the entries for each Map and if nothing is in for 
the current key, put it in
Set resultKeySet = new HashSet();
culprit --> Set> resultEntrySet = new ListSet>();
for (Map curMap: this.stackList) {
for (Map.Entry curEntry: curMap.entrySet()) {
if (!resultKeySet.contains(curEntry.getKey())) {
resultKeySet.add(curEntry.getKey());
resultEntrySet.add(curEntry);
}
}
}
return Collections.unmodifiableSet(resultEntrySet);
}
{code}

Looking at the java api for Map.Entry, the hashCode method for Map.Entry is the 
result of the hashCode from both key and value. ByteBuffer hash code is 
dependent upon its content. If a 2mb file is uploaded, the hashCode method
of ByteBuffer will scan 2mb to generate the hashCode

ByteBuffer
http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#hashCode()
{quote}Because buffer hash codes are content-dependent, it is inadvisable to 
use buffers as keys in hash maps or similar data structures unless it is known 
that their contents will not change.{quote}

Map.Entry
http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode()
{quote}(e.getKey()==null   ? 0 : e.getKey().hashCode()) ^ (e.getValue()==null ? 
0 : e.getValue().hashCode()){quote}

HashSet
http://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html
{quote}This class implements the Set interface, backed by a hash table 
(actually a HashMap instance{quote}

Example where ByteBuffer objects are created
{code}org.ofbiz.webapp.event.ServiceEventHandler{code}

Example stack trace
{noformat}
"ajp-bio-8009-exec-1894" daemon prio=10 tid=0x7fa52c07 nid=0x5c73 
runnable [0x7fa51151b000]
   java.lang.Thread.State: RUNNABLE
at java.nio.HeapByteBuffer.ix(HeapByteBuffer.java:131)
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:139)
at java.nio.ByteBuffer.hashCode(ByteBuffer.java:1083)
at java.util.Objects.hashCode(Objects.java:96)
at java.util.HashMap$Entry.hashCode(HashMap.java:847)
at java.util.AbstractMap.hashCode(AbstractMap.java:494)
at java.util.Objects.hashCode(Objects.java:96)
at java.util.HashMap$Entry.hashCode(HashMap.java:847)
at java.util.HashMap.hash(HashMap.java:362)
at java.util.HashMap.put(HashMap.java:492)
at java.util.HashSet.add(HashSet.java:217)
at 
org.ofbiz.base.util.collections.MapContext.entrySet(MapContext.java:306)
at java.util.HashMap.putAll(HashMap.java:642)
at 
org.ofbiz.widget.model.ModelFormField$ListOptions.addOptionValues(ModelFormField.java:2716)
at 
org.ofbiz.widget.model.ModelFormField$FieldInfoWithOptions.getAllOptionValues(ModelFormField.java:1985)
at 
org.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDropDownField(MacroFormRenderer.java:747)
at 
org.ofbiz.widget.model.ModelFormField$DropDownField.renderFieldString(ModelFormField.java:1739)
at 
org.ofbiz.widget.model.ModelFormField.renderFieldString(ModelFormField.java:693)
at 
org.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(FormRenderer.java:1195)
at org.ofbiz.widget.renderer.FormRenderer.render(FormRenderer.java:261)
at 
org.ofbiz.widget.model.ModelScreenWidget$Form.renderWidgetString(ModelScreenWidget.java:1052)
at 
org.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderScreenletSubWidget(MacroScreenRenderer.java:677)
at 
org.ofbiz.widget.model.ModelScreenWidget$Screenlet.renderWidgetString(ModelScreenWidget.java:598)
at 
org.ofbiz.widget.model.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:98)
at 
org.ofbiz.widget.model.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:280)
at 
org.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:164)
at 
org.ofbiz.widget.model.ScreenFactory.renderReferencedScreen(ScreenFactory.java:211)
at 
org.ofbiz.widget.model.ModelScreenWidget$IncludeScreen.renderWidgetString(ModelScreenWidget.java:779)
at 

[jira] [Updated] (OFBIZ-6621) MapContext.entrySet() slows down when ByteBuffer objects are in the context

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6621:
-
Attachment: MapContext.patch

Patch uses a Set backed by a List instead. Currently testing this on our dev box

> MapContext.entrySet() slows down when ByteBuffer objects are in the context
> ---
>
> Key: OFBIZ-6621
> URL: https://issues.apache.org/jira/browse/OFBIZ-6621
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Critical
> Attachments: MapContext.patch
>
>
> When MapContext is used anywhere (eg FlexibleStringExpander) and the context 
> contains ByteBuffer objects (either key or value), java will slow down when 
> calling MapContext.entrySet().
> Here is the code in ofbiz, highlighted is the line of code that I believe is 
> the culprit
> {code:title=MapContext.java}
> public Set> entrySet() {
> // walk the stackList and the entries for each Map and if nothing is in 
> for the current key, put it in
> Set resultKeySet = new HashSet();
> culprit --> Set> resultEntrySet = new 
> ListSet>();
> for (Map curMap: this.stackList) {
> for (Map.Entry curEntry: curMap.entrySet()) {
> if (!resultKeySet.contains(curEntry.getKey())) {
> resultKeySet.add(curEntry.getKey());
> resultEntrySet.add(curEntry);
> }
> }
> }
> return Collections.unmodifiableSet(resultEntrySet);
> }
> {code}
> Looking at the java api for Map.Entry, the hashCode method for Map.Entry is 
> the result of the hashCode from both key and value. ByteBuffer hash code is 
> dependent upon its content. If a 2mb file is uploaded, the hashCode method
> of ByteBuffer will scan 2mb to generate the hashCode
> ByteBuffer
> http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#hashCode()
> {quote}Because buffer hash codes are content-dependent, it is inadvisable to 
> use buffers as keys in hash maps or similar data structures unless it is 
> known that their contents will not change.{quote}
> Map.Entry
> http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode()
> {quote}(e.getKey()==null   ? 0 : e.getKey().hashCode()) ^ (e.getValue()==null 
> ? 0 : e.getValue().hashCode()){quote}
> HashSet
> http://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html
> {quote}This class implements the Set interface, backed by a hash table 
> (actually a HashMap instance{quote}
> Example where ByteBuffer objects are created
> {code}org.ofbiz.webapp.event.ServiceEventHandler{code}
> Example stack trace
> {noformat}
> "ajp-bio-8009-exec-1894" daemon prio=10 tid=0x7fa52c07 nid=0x5c73 
> runnable [0x7fa51151b000]
>java.lang.Thread.State: RUNNABLE
>   at java.nio.HeapByteBuffer.ix(HeapByteBuffer.java:131)
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:139)
>   at java.nio.ByteBuffer.hashCode(ByteBuffer.java:1083)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.AbstractMap.hashCode(AbstractMap.java:494)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.HashMap.hash(HashMap.java:362)
>   at java.util.HashMap.put(HashMap.java:492)
>   at java.util.HashSet.add(HashSet.java:217)
>   at 
> org.ofbiz.base.util.collections.MapContext.entrySet(MapContext.java:306)
>   at java.util.HashMap.putAll(HashMap.java:642)
>   at 
> org.ofbiz.widget.model.ModelFormField$ListOptions.addOptionValues(ModelFormField.java:2716)
>   at 
> org.ofbiz.widget.model.ModelFormField$FieldInfoWithOptions.getAllOptionValues(ModelFormField.java:1985)
>   at 
> org.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDropDownField(MacroFormRenderer.java:747)
>   at 
> org.ofbiz.widget.model.ModelFormField$DropDownField.renderFieldString(ModelFormField.java:1739)
>   at 
> org.ofbiz.widget.model.ModelFormField.renderFieldString(ModelFormField.java:693)
>   at 
> org.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(FormRenderer.java:1195)
>   at org.ofbiz.widget.renderer.FormRenderer.render(FormRenderer.java:261)
>   at 
> org.ofbiz.widget.model.ModelScreenWidget$Form.renderWidgetString(ModelScreenWidget.java:1052)
>   at 
> org.ofbiz.widget.renderer.macro.MacroScreenRenderer.renderScreenletSubWidget(MacroScreenRenderer.java:677)
>   at 
> org.ofbiz.widget.model.ModelScreenWidget$Screenlet.renderWidgetString(ModelScreenWidget.java:598)
>   at 
> 

[jira] [Commented] (OFBIZ-6621) MapContext.entrySet() slows down when ByteBuffer objects are in the context

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6621:
--

I wouldn't be against this idea but there are 2 source files that use 
HashSet>

grep -R --exclude-dir=.svn "HashSet> resultEntrySet = new HashSet>();
./framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java:   
 Set> tempSet = new HashSet>();

Whether we need to be worry about CollectionConverters.java I do not know.

Its a shame commons does not provide a similar class to ListSet

> MapContext.entrySet() slows down when ByteBuffer objects are in the context
> ---
>
> Key: OFBIZ-6621
> URL: https://issues.apache.org/jira/browse/OFBIZ-6621
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Critical
> Attachments: MapContext.patch
>
>
> When MapContext is used anywhere (eg FlexibleStringExpander) and the context 
> contains ByteBuffer objects (either key or value), java will slow down when 
> calling MapContext.entrySet().
> Here is the code in ofbiz, highlighted is the line of code that I believe is 
> the culprit
> {code:title=MapContext.java}
> public Set> entrySet() {
> // walk the stackList and the entries for each Map and if nothing is in 
> for the current key, put it in
> Set resultKeySet = new HashSet();
> culprit --> Set> resultEntrySet = new 
> ListSet>();
> for (Map curMap: this.stackList) {
> for (Map.Entry curEntry: curMap.entrySet()) {
> if (!resultKeySet.contains(curEntry.getKey())) {
> resultKeySet.add(curEntry.getKey());
> resultEntrySet.add(curEntry);
> }
> }
> }
> return Collections.unmodifiableSet(resultEntrySet);
> }
> {code}
> Looking at the java api for Map.Entry, the hashCode method for Map.Entry is 
> the result of the hashCode from both key and value. ByteBuffer hash code is 
> dependent upon its content. If a 2mb file is uploaded, the hashCode method
> of ByteBuffer will scan 2mb to generate the hashCode
> ByteBuffer
> http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#hashCode()
> {quote}Because buffer hash codes are content-dependent, it is inadvisable to 
> use buffers as keys in hash maps or similar data structures unless it is 
> known that their contents will not change.{quote}
> Map.Entry
> http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode()
> {quote}(e.getKey()==null   ? 0 : e.getKey().hashCode()) ^ (e.getValue()==null 
> ? 0 : e.getValue().hashCode()){quote}
> HashSet
> http://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html
> {quote}This class implements the Set interface, backed by a hash table 
> (actually a HashMap instance{quote}
> Example where ByteBuffer objects are created
> {code}org.ofbiz.webapp.event.ServiceEventHandler{code}
> Example stack trace
> {noformat}
> "ajp-bio-8009-exec-1894" daemon prio=10 tid=0x7fa52c07 nid=0x5c73 
> runnable [0x7fa51151b000]
>java.lang.Thread.State: RUNNABLE
>   at java.nio.HeapByteBuffer.ix(HeapByteBuffer.java:131)
>   at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:139)
>   at java.nio.ByteBuffer.hashCode(ByteBuffer.java:1083)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.AbstractMap.hashCode(AbstractMap.java:494)
>   at java.util.Objects.hashCode(Objects.java:96)
>   at java.util.HashMap$Entry.hashCode(HashMap.java:847)
>   at java.util.HashMap.hash(HashMap.java:362)
>   at java.util.HashMap.put(HashMap.java:492)
>   at java.util.HashSet.add(HashSet.java:217)
>   at 
> org.ofbiz.base.util.collections.MapContext.entrySet(MapContext.java:306)
>   at java.util.HashMap.putAll(HashMap.java:642)
>   at 
> org.ofbiz.widget.model.ModelFormField$ListOptions.addOptionValues(ModelFormField.java:2716)
>   at 
> org.ofbiz.widget.model.ModelFormField$FieldInfoWithOptions.getAllOptionValues(ModelFormField.java:1985)
>   at 
> org.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDropDownField(MacroFormRenderer.java:747)
>   at 
> org.ofbiz.widget.model.ModelFormField$DropDownField.renderFieldString(ModelFormField.java:1739)
>   at 
> org.ofbiz.widget.model.ModelFormField.renderFieldString(ModelFormField.java:693)
>   at 
> org.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(FormRenderer.java:1195)
>   at 

[jira] [Updated] (OFBIZ-6619) PurgeJob.java does not delete RecurrenceRule because it is still referenced by RecurrenceInfo

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6619:
-
Summary: PurgeJob.java does not delete RecurrenceRule because it is still 
referenced by RecurrenceInfo  (was: PurgeJob.java does not delete 
RecurrenceRule because it is still referenced RecurrenceInfo)

> PurgeJob.java does not delete RecurrenceRule because it is still referenced 
> by RecurrenceInfo
> -
>
> Key: OFBIZ-6619
> URL: https://issues.apache.org/jira/browse/OFBIZ-6619
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: PurgeJob.patch
>
>
> Need to remove RecurrenceInfo first. 
> Minor but very annoying to see db and ofbiz log files filled up with errors



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6619) PurgeJob.java does not delete RecurrenceRule because it is still referenced RecurrenceInfo

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6619:
-
Attachment: PurgeJob.patch

> PurgeJob.java does not delete RecurrenceRule because it is still referenced 
> RecurrenceInfo
> --
>
> Key: OFBIZ-6619
> URL: https://issues.apache.org/jira/browse/OFBIZ-6619
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Priority: Trivial
> Attachments: PurgeJob.patch
>
>
> Need to remove RecurrenceInfo first. 
> Minor but very annoying to see db and ofbiz log files filled up with errors



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6619) PurgeJob.java does not delete RecurrenceRule because it is still referenced RecurrenceInfo

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6619:


 Summary: PurgeJob.java does not delete RecurrenceRule because it 
is still referenced RecurrenceInfo
 Key: OFBIZ-6619
 URL: https://issues.apache.org/jira/browse/OFBIZ-6619
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: PurgeJob.patch

Need to remove RecurrenceInfo first. 

Minor but very annoying to see db and ofbiz log files filled up with errors



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6567) Wrong percent encoding in Webtool/SQL Processor

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6567:
--

I was looking for that link. I completely agree with it, Seems like 
canonicalize would be better at service parameter level or called within an 
event (or anywhere else where request parameters are manually read). This give 
developers the choice

I had a similar issue with a WYSIWYG editor, the uploaded html with encoded 
ampersands amp; were decoded to  but then attempting to read that html into 
DOM gave an error because  is not valid in xml. 

And of course OFBIZ-5910

 Wrong percent encoding in Webtool/SQL Processor
 ---

 Key: OFBIZ-6567
 URL: https://issues.apache.org/jira/browse/OFBIZ-6567
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
 Branch 14.12, Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: 14.12.01, 12.04.06, 13.07.03, Upcoming Branch


 This was reported to me by Gareth Carter, the investigation is mine.
 If for instance you use this SQL expression
 {code}
 select * from Party_Role where role_Type_Id LIKE  '%CA%'
 {code}
 It will be interpreted (and returned to UI) as
 {code}
 select * from Party_Role where role_Type_Id LIKE  'Ê%'
 {code}
 And no result will be returned when OOTB there is  6 PartyRole partyId=*** 
 roleTypeId=CARRIER/ entities
 This is because in UtilHttp.canonicalizeParameterMap() 
 UtilHttp.canonicalizeParameter() is called. And inside the later 
 UtilCodec.canonicalize() is used. So 2 ESAPI codecs are tested 
 HTMLEntityCodec.decode() and PercentCodec.decode(). Only 
 PercentCodec.decode() does a change so it's picked. In this case it should 
 not, because nothing should be decoded. At this point, nothing has been 
 encoded, the String the codec decodes is still select * from Party_Role 
 where role_Type_Id LIKE  '%CA%'
 I read at https://en.wikipedia.org/wiki/Percent-encoding that though mostly 
 planned for URL encoding  percent encoding
 bq. is also used in the preparation of data of the 
 application/x-www-form-urlencoded media type, as is often used in the 
 submission of HTML form data in HTTP requests.
 But in the specific case of a like in an SQL expression coming from the text 
 area of webtools/control/EntitySQLProcessor it should not be used because the 
 % followed by some chars, may be wrongly decoded.
 Because there are no other ways provided by the percent codec to prevent the 
 decoding (it's supposed to have been encoded before), I'm not quite proud of 
 it but I found only this workaround so far
 {code}
 Index: framework/base/src/org/ofbiz/base/util/UtilCodec.java
 ===
 --- framework/base/src/org/ofbiz/base/util/UtilCodec.java (revision 
 1693397)
 +++ framework/base/src/org/ofbiz/base/util/UtilCodec.java (working copy)
 @@ -164,16 +164,24 @@
  while (i.hasNext()) {
  Codec codec = i.next();
  String old = working;
 -working = codec.decode(working);
 -if (!old.equals(working)) {
 -if (codecFound != null  codecFound != codec) {
 -mixedCount++;
 +String upperWorking = working.toUpperCase();
 +if (codec instanceof PercentCodec
 + upperWorking.contains(WHERE)
 + upperWorking.contains(LIKE)
 + upperWorking.contains(%)) {
 +continue;
 +} else {
 +working = codec.decode(working);
 +if (!old.equals(working)) {
 +if (codecFound != null  codecFound != codec) {
 +mixedCount++;
 +}
 +codecFound = codec;
 +if (clean) {
 +foundCount++;
 +}
 +clean = false;
  }
 -codecFound = codec;
 -if (clean) {
 -foundCount++;
 -}
 -clean = false;
  }
  }
  }
 {code}
 Better ideas?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6567) Wrong percent encoding in Webtool/SQL Processor

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6567:
--

I dislike modifying UtilCodec in this way. Its very much a band aid on a 
problem that shouldn't exist anyway. Percent encoding is used on query 
parameters and form parameters, the servlet container (tomcat in this instance) 
has already percent decoded parameters so why attempt to do it again?

Example:
1) User types in sql  select * from Party_Role where role_Type_Id LIKE  '%CA%' 
 in text area and submits.
2) The browser sends 
group=org.ofbizsqlCommand=select+*+from+Party_Role+where+role_Type_Id+LIKE++%27%25CA%25%27rowLimit=200submitButton=Submit
 as form parameters to server
3) Tomcat decodes each parameter so the sqlCommand parameter from 
HttpServletRequest reads  select * from Party_Role where role_Type_Id LIKE  
'%CA%' 
4) UtilCodec decodes the correct request parameter and modifies it because it 
has detected a valid percent encoding (%CA). The output is finally  select * 
from Party_Role where role_Type_Id LIKE  'Ê%' 


A quick win would be to modify EntitySQLProcessor.groovy and add:

sqlCommand = context.request.getParameter(sqlCommand);
context.sqlCommand = sqlCommand;

I would suggest not to percent decode or canonicalize request parameters, I 
doubt there would be little impact on removing percent decoding from request 
parameters but unsure about html entity decoding

 Wrong percent encoding in Webtool/SQL Processor
 ---

 Key: OFBIZ-6567
 URL: https://issues.apache.org/jira/browse/OFBIZ-6567
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
 Branch 14.12, Trunk
Reporter: Jacques Le Roux
Priority: Minor

 This was reported to me by Gareth Carter, the investigation is mine.
 If for instance you use this SQL expression
 {code}
 select * from Party_Role where role_Type_Id LIKE  '%CA%'
 {code}
 It will be interpreted (and returned to UI) as
 {code}
 select * from Party_Role where role_Type_Id LIKE  'Ê%'
 {code}
 And no result will be returned when OOTB there is  6 PartyRole partyId=*** 
 roleTypeId=CARRIER/ entities
 This is because in UtilHttp.canonicalizeParameterMap() 
 UtilHttp.canonicalizeParameter() is called. And inside the later 
 UtilCodec.canonicalize() is used. So 2 ESAPI codecs are tested 
 HTMLEntityCodec.decode() and PercentCodec.decode(). Only 
 PercentCodec.decode() does a change so it's picked. In this case it should 
 not, because nothing should be decoded. At this point, nothing has been 
 encoded, the String the codec decodes is still select * from Party_Role 
 where role_Type_Id LIKE  '%CA%'
 I read at https://en.wikipedia.org/wiki/Percent-encoding that though mostly 
 planned for URL encoding  percent encoding
 bq. is also used in the preparation of data of the 
 application/x-www-form-urlencoded media type, as is often used in the 
 submission of HTML form data in HTTP requests.
 But in the specific case of a like in an SQL expression coming from the text 
 area of webtools/control/EntitySQLProcessor it should not be used because the 
 % followed by some chars, may be wrongly decoded.
 Because there are no other ways provided by the percent codec to prevent the 
 decoding (it's supposed to have been encoded before), I'm not quite proud of 
 it but I found only this workaround so far
 {code}
 Index: framework/base/src/org/ofbiz/base/util/UtilCodec.java
 ===
 --- framework/base/src/org/ofbiz/base/util/UtilCodec.java (revision 
 1693397)
 +++ framework/base/src/org/ofbiz/base/util/UtilCodec.java (working copy)
 @@ -164,16 +164,24 @@
  while (i.hasNext()) {
  Codec codec = i.next();
  String old = working;
 -working = codec.decode(working);
 -if (!old.equals(working)) {
 -if (codecFound != null  codecFound != codec) {
 -mixedCount++;
 +String upperWorking = working.toUpperCase();
 +if (codec instanceof PercentCodec
 + upperWorking.contains(WHERE)
 + upperWorking.contains(LIKE)
 + upperWorking.contains(%)) {
 +continue;
 +} else {
 +working = codec.decode(working);
 +if (!old.equals(working)) {
 +if (codecFound != null  codecFound != codec) {
 +mixedCount++;
 +}
 +codecFound = codec;
 +if (clean) {
 +

[jira] [Comment Edited] (OFBIZ-6567) Wrong percent encoding in Webtool/SQL Processor

[Gareth Carter (JIRA)]

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

Gareth Carter edited comment on OFBIZ-6567 at 7/31/15 9:56 AM:
---

I dislike modifying UtilCodec in this way. Its very much a band aid on a 
problem that shouldn't exist anyway. Percent encoding is used on query 
parameters and form parameters, the servlet container (tomcat in this instance) 
has already percent decoded parameters so why attempt to do it again?

{noformat}
Example:
1) User types in sql  select * from Party_Role where role_Type_Id LIKE  '%CA%' 
 in text area and submits.
2) The browser sends 
group=org.ofbizsqlCommand=select+*+from+Party_Role+where+role_Type_Id+LIKE++%27%25CA%25%27rowLimit=200submitButton=Submit
 as form parameters to server
3) Tomcat decodes each parameter so the sqlCommand parameter from 
HttpServletRequest reads  select * from Party_Role where role_Type_Id LIKE  
'%CA%' 
4) UtilCodec decodes the correct request parameter and modifies it because it 
has detected a valid percent encoding (%CA). The output is finally  select * 
from Party_Role where role_Type_Id LIKE  'Ê%' 
{noformat}

A quick win would be to modify EntitySQLProcessor.groovy and add:

sqlCommand = context.request.getParameter(sqlCommand);
context.sqlCommand = sqlCommand;

I would suggest not to percent decode or canonicalize request parameters, I 
doubt there would be little impact on removing percent decoding from request 
parameters but unsure about html entity decoding


was (Author: gareth.carter):
I dislike modifying UtilCodec in this way. Its very much a band aid on a 
problem that shouldn't exist anyway. Percent encoding is used on query 
parameters and form parameters, the servlet container (tomcat in this instance) 
has already percent decoded parameters so why attempt to do it again?

Example:
1) User types in sql  select * from Party_Role where role_Type_Id LIKE  '%CA%' 
 in text area and submits.
2) The browser sends 
group=org.ofbizsqlCommand=select+*+from+Party_Role+where+role_Type_Id+LIKE++%27%25CA%25%27rowLimit=200submitButton=Submit
 as form parameters to server
3) Tomcat decodes each parameter so the sqlCommand parameter from 
HttpServletRequest reads  select * from Party_Role where role_Type_Id LIKE  
'%CA%' 
4) UtilCodec decodes the correct request parameter and modifies it because it 
has detected a valid percent encoding (%CA). The output is finally  select * 
from Party_Role where role_Type_Id LIKE  'Ê%' 


A quick win would be to modify EntitySQLProcessor.groovy and add:

sqlCommand = context.request.getParameter(sqlCommand);
context.sqlCommand = sqlCommand;

I would suggest not to percent decode or canonicalize request parameters, I 
doubt there would be little impact on removing percent decoding from request 
parameters but unsure about html entity decoding

 Wrong percent encoding in Webtool/SQL Processor
 ---

 Key: OFBIZ-6567
 URL: https://issues.apache.org/jira/browse/OFBIZ-6567
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
 Branch 14.12, Trunk
Reporter: Jacques Le Roux
Priority: Minor

 This was reported to me by Gareth Carter, the investigation is mine.
 If for instance you use this SQL expression
 {code}
 select * from Party_Role where role_Type_Id LIKE  '%CA%'
 {code}
 It will be interpreted (and returned to UI) as
 {code}
 select * from Party_Role where role_Type_Id LIKE  'Ê%'
 {code}
 And no result will be returned when OOTB there is  6 PartyRole partyId=*** 
 roleTypeId=CARRIER/ entities
 This is because in UtilHttp.canonicalizeParameterMap() 
 UtilHttp.canonicalizeParameter() is called. And inside the later 
 UtilCodec.canonicalize() is used. So 2 ESAPI codecs are tested 
 HTMLEntityCodec.decode() and PercentCodec.decode(). Only 
 PercentCodec.decode() does a change so it's picked. In this case it should 
 not, because nothing should be decoded. At this point, nothing has been 
 encoded, the String the codec decodes is still select * from Party_Role 
 where role_Type_Id LIKE  '%CA%'
 I read at https://en.wikipedia.org/wiki/Percent-encoding that though mostly 
 planned for URL encoding  percent encoding
 bq. is also used in the preparation of data of the 
 application/x-www-form-urlencoded media type, as is often used in the 
 submission of HTML form data in HTTP requests.
 But in the specific case of a like in an SQL expression coming from the text 
 area of webtools/control/EntitySQLProcessor it should not be used because the 
 % followed by some chars, may be wrongly decoded.
 Because there are no other ways provided by the percent codec to prevent the 
 decoding (it's supposed to have been encoded before), I'm not quite 

[jira] [Commented] (OFBIZ-6504) how to Create PDF with password Protected in Ofbiz

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6504:
--

MacroFormRenderer is creating adhoc freemarker scripts and therefore should 
escape all special characters from all sources. If percent/entity encoding is 
happening prior to generating the freemarker then these encoded values need to 
be escaped too.

Eg #x27; should be \a#x27;

Not exactly sure why you have to replace %27, you should only need to percent 
encode url parameters, the description field above (from the patch) should 
contain a ' apostrophe not %27. 

 how to Create PDF with password Protected in Ofbiz
 --

 Key: OFBIZ-6504
 URL: https://issues.apache.org/jira/browse/OFBIZ-6504
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
 Environment: linux
Reporter: Sachin Manjule
Assignee: Shi Jinghai
Priority: Trivial
 Fix For: Upcoming Branch

 Attachments: localhost.png, trunk demo.png


 We can create PDF using FTL that is OK, but how to generate PDF with 
 Encryption password protected?
 itext is best option for this. but can we emmber in ftl or other places?
 pleas Help us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6504) how to Create PDF with password Protected in Ofbiz

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6504:
--

Seems to me like you have to escape special chars. See 
http://freemarker.org/docs/dgui_template_exp.html - escape sequences. 
Apostrophe is one of those special chars

 how to Create PDF with password Protected in Ofbiz
 --

 Key: OFBIZ-6504
 URL: https://issues.apache.org/jira/browse/OFBIZ-6504
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
 Environment: linux
Reporter: Sachin Manjule
Assignee: Shi Jinghai
Priority: Trivial
 Fix For: Upcoming Branch

 Attachments: localhost.png, trunk demo.png


 We can create PDF using FTL that is OK, but how to generate PDF with 
 Encryption password protected?
 itext is best option for this. but can we emmber in ftl or other places?
 pleas Help us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6537) Unable to change users timezone for session

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6537:


 Summary: Unable to change users timezone for session
 Key: OFBIZ-6537
 URL: https://issues.apache.org/jira/browse/OFBIZ-6537
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Gareth Carter


Login as admin and change the timezone, the timezone displayed at the bottom 
does not change however the lastTimeZone value in UserLogin does change.

If you log out and login again, you may see the page after login will display 
the correct timezone but all other pages accessed afterwards display either the 
previous value or the system timezone.

Caching issue?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Can't test due to https://issues.apache.org/jira/browse/OFBIZ-6537. I have yet 
to find the cause

 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
 dates.patch, dates_1589040.patch, sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6536) The Create new link under partymgr has disappeared

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6536:


 Summary: The Create new link under partymgr has disappeared
 Key: OFBIZ-6536
 URL: https://issues.apache.org/jira/browse/OFBIZ-6536
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

I do not know if it does rounding - but it certainly seems to ignore the time 
when storing and normalizes the time to midnight on retrieval as per API. You 
just set the time to midnight in the converters which should happen anyway.

I don't believe there will be any data corruption if app servers have different 
timezones. If you use the system timezone on any instance to create a 
java.sql.Date from a string and store that java.sql.Date into the database 
using PreparedStatement.setDate(i, x) then the output of toString() will be 
what is stored in the database. Personally I believe most jdbc drivers work 
with the year/month/day values that the java.sql.Date represents in the system 
timezone rather than the millisecond value that is actually used

 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
 dates.patch, dates_1589040.patch, sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

It looks fine. I have concerns though about all the existing fields that use 
SQL Date - will these get updated with ignore-time-zone=true?

With a little digging I can see the following entities that use SQL Date:

$ grep -R --exclude-dir=.svn --include=*.xml type=\date\ . | grep 
entitydef
./applications/accounting/entitydef/entitymodel.xml:field 
name=expectedEndOfLife type=date/field
./applications/accounting/entitydef/entitymodel.xml:field 
name=actualEndOfLife type=date/field
./applications/accounting/entitydef/entitymodel.xml:  field name=dueDate 
type=date/field
./applications/humanres/entitydef/entitymodel.xml:field 
name=jobRequisitionDate type=date/field
./applications/humanres/entitydef/entitymodel.xml:field 
name=requiredOnDate type=date/field
./applications/humanres/entitydef/entitymodel.xml:field 
name=jobInterviewDate type=date/field
./applications/manufacturing/entitydef/entitymodel.xml:  field 
name=exceptionDateStart type=date/field
./applications/order/entitydef/entitymodel.xml:  field name=entryDate 
type=date/field
./applications/party/entitydef/entitymodel.xml:  field name=birthDate 
type=date/field
./applications/party/entitydef/entitymodel.xml:  field name=deceasedDate 
type=date/field
./applications/party/entitydef/entitymodel.xml:  field 
name=passportExpireDate type=date/field
./framework/common/entitydef/entitymodel.xml:  field name=fromDate 
type=date/field
./framework/common/entitydef/entitymodel.xml:  field name=thruDate 
type=date/field
./framework/entity/entitydef/entitymodel_test.xml:field 
name=dateField type=date/
./specialpurpose/bi/entitydef/entitymodel.xml:field name=dateValue 
type=date


 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
 dates.patch, dates_1589040.patch, sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

I will confirm and get back to you but on initial inspection of the patch, it 
seems like it would do the job.

I doubt that this would be useful for anything but java.sql.Date and maybe 
java.sql.Time. It makes no sense to apply a different timezone to java.sql.Date 
when you don't know the time or to java.sql.Time when you don't know the date.

I supposed for java.sql.Time you could use the current date but depending on 
the system timezone, user's timezone and current date the outcome could change 
from one day to another (eg DST)

 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: IgnoreTimeZone.patch, ObjectTypeTests.patch, 
 dates.patch, dates_1589040.patch, sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

Forgot to mention, I have observed this behaviour with 3 jdbc drivers, derby, 
postgresql and mysql. Seems to me like these jdbc drivers do as per API spec 
but other jdbc drivers may work differently

 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: ObjectTypeTests.patch, dates.patch, dates_1589040.patch, 
 sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-5608:
--

I believe it would have to be systems timezone as the jdbc driver uses the 
system timezone when setting and pulling java.sql.Date (and others!) but this 
should only apply to java.sql.Date

If you use UTC, it will still causes issues if the systems timezone is not UTC

 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: ObjectTypeTests.patch, dates.patch, dates_1589040.patch, 
 sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-5608:
-
Attachment: sqldate_scenarios.png

As suggested by Adrian,

I have attached an image of 3 flow diagrams depicting what I believe is 
happening when using java.sql.Date and db type SQL DATE with different 
timezones for user, app server and database server. 

 Dates Displaying Incorrectly With Negative Offest Timezones.
 

 Key: OFBIZ-5608
 URL: https://issues.apache.org/jira/browse/OFBIZ-5608
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Rupert Howell
Priority: Minor
 Attachments: ObjectTypeTests.patch, dates.patch, dates_1589040.patch, 
 sqldate_scenarios.png


 Dates are displaying incorrectly when negative offset (relative to UTC) are 
 applied by the users settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6386:
-
Attachment: v2.patch
v1.patch

v1.patch removes the compareBigDecimals code entirely

v2.patch updates the compareBigDecimals method to up the scale so its a smaller 
patch with minimal code change.

Personally, I would use v1.patch and remove the code. compareBigDecimals calls 
BigDecimal.compareTo but it modifies the value before calling compareTo

 compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
 compare certain values correctly
 -

 Key: OFBIZ-6386
 URL: https://issues.apache.org/jira/browse/OFBIZ-6386
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor
 Attachments: compareBigDecimals.png, v1.patch, v2.patch


 Moving the conversation from https://issues.apache.org/jira/browse/OFBIZ-6291 
 to this issue.
 compareBigDecimals scales down and rounds up meaning you lose information and 
 the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6414) drop-down widget field with allow-multiple=true does not display current value

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6414:


 Summary: drop-down widget field with allow-multiple=true does 
not display current value
 Key: OFBIZ-6414
 URL: https://issues.apache.org/jira/browse/OFBIZ-6414
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor


ModelFormField.getEntry returns the string representation of the value 
corresponding to the field in either the context map or parameters map but when 
the value is returned as a list [X, Y, Z], the opening and closing brackets are 
encoded #x5b;X, Y, Z#x5d;

This prevents the FormRenderer (atleast MacroFormRenderer) from detecting a 
list object from the string and converting it back to a list
eg - currentValueList = StringUtil.toList(currentValue);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6414) drop-down widget field with allow-multiple=true does not display current value

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6414:
-
Attachment: ModelFormField.patch

Attached is a patch that fixes the issue with drop-down widget. The patch will 
encode all the values inside the collection and return's the string 
representation as [X, Y, Z]. 

Just to point out, the Collection interface does not state the toString() 
method should return the string representation as [X, Y, Z] but the 
AbstractCollection does. If, for whatever reason, a Collection was used that 
does not inherit AbstractCollection, the field will not be populated with any 
stored values. Luckily it seems ofbiz does not use this type of field and 
Jacques has pointed out to me variants of this type of UI that may well be used 
instead

 drop-down widget field with allow-multiple=true does not display current 
 value
 

 Key: OFBIZ-6414
 URL: https://issues.apache.org/jira/browse/OFBIZ-6414
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor
 Attachments: ModelFormField.patch


 ModelFormField.getEntry returns the string representation of the value 
 corresponding to the field in either the context map or parameters map but 
 when the value is returned as a list [X, Y, Z], the opening and closing 
 brackets are encoded #x5b;X, Y, Z#x5d;
 This prevents the FormRenderer (atleast MacroFormRenderer) from detecting a 
 list object from the string and converting it back to a list
 eg - currentValueList = StringUtil.toList(currentValue);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6276:
--

What about new method that allows passing in an options object

storeAll(ListGenericValue values, StoreOptions options) ?

You can deprecate the old methods without changes

Moving forward, you would just need to add new values to the StoreOptions class 
rather than adding new parameters to the existing one

I am not sure about the name StoreOptions though, EntityOptions ?

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Jacques Le Roux
Priority: Minor
 Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6291:
--

Thanks Adrian.

 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk, Upcoming Branch
Reporter: Gareth Carter
Assignee: Adrian Crum
Priority: Trivial
 Fix For: Upcoming Branch

 Attachments: LocalizedConverters.patch, minilang_compare.patch, 
 minilang_compare_r1675655.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6386:
--

It may not perform calculations directly but it is a control statement in 
minilang, therefore calculations (or other code) may occur that were not 
expected. 

I only analysed ofbiz for usage not impact. I noticed the accounting component 
used if-compare and if-compare-field with type=BigDecimal and with 
accounting you generally want accuracy in terms of numbers, BigDecimal offers 
this
but, to me compareBigDecimals does not. You lose information on comparison.

Java code in ofbiz generally uses compareTo for comparison without modifying 
scale.

Groovy code is the same as java (using compareTo), groovy also supports 
operator overloading which will use compareTo for relational operator 
overloading (eg, a == b)

The compareBigDecimals method used in minilang behaves slightly different to 
those comparisons done in java or groovy but only for values like those in 
compareBigDecimals.png


I will provide a patch for review as soon as I can

 compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
 compare certain values correctly
 -

 Key: OFBIZ-6386
 URL: https://issues.apache.org/jira/browse/OFBIZ-6386
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor
 Attachments: compareBigDecimals.png


 Moving the conversation from https://issues.apache.org/jira/browse/OFBIZ-6291 
 to this issue.
 compareBigDecimals scales down and rounds up meaning you lose information and 
 the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6386:
--

Also, the method has a comment

// Developers: Do not change this. We are comparing two fixed-point 
decimal numbers,
// not performing accounting calculations - so it is okay to specify 
the rounding mode.

But searching ofbiz for if-compare and if-compare-field in minilang, you will 
find them in accounting component...

 compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
 compare certain values correctly
 -

 Key: OFBIZ-6386
 URL: https://issues.apache.org/jira/browse/OFBIZ-6386
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor
 Attachments: compareBigDecimals.png


 Moving the conversation from https://issues.apache.org/jira/browse/OFBIZ-6291 
 to this issue.
 compareBigDecimals scales down and rounds up meaning you lose information and 
 the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

Gareth Carter created OFBIZ-6386:


 Summary: compareBigDecimals in 
org.ofbiz.minilang.method.conditional.Compare does not compare certain values 
correctly
 Key: OFBIZ-6386
 URL: https://issues.apache.org/jira/browse/OFBIZ-6386
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor


Moving the conversation from https://issues.apache.org/jira/browse/OFBIZ-6291 
to this issue.

compareBigDecimals scales down and rounds up meaning you lose information and 
the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

[Gareth Carter (JIRA)]

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

Gareth Carter updated OFBIZ-6386:
-
Attachment: compareBigDecimals.png

compareBigDecimals.png shows the output of 5 different methods. The first table 
shows the result from the code in ofbiz - basically it treats all those values 
as equal to each other

The second table shows a slightly modified version where the BigDecimals are 
scaled and rounded up (eg 2.01 will become 2.010). The result for this scenario 
is the same as BigDecimal.compareTo where compareTo method ignores scale

The 4th table (BigDecimal.equals) is just there as a comparison and proves the 
result is false because the scale is different for each value

The 5th table, I have added only because if-compare and if-compare-field in 
minilang default to converting objects to their string representation before 
performing comparison (String.compareTo). The result is slightly different 
because compareTo compares lexicographically, 2.010 and 2.01 are the same 
numerically (ignoring scale), 2.010 and 2.01 are lexicographically different

 compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
 compare certain values correctly
 -

 Key: OFBIZ-6386
 URL: https://issues.apache.org/jira/browse/OFBIZ-6386
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Minor
 Attachments: compareBigDecimals.png


 Moving the conversation from https://issues.apache.org/jira/browse/OFBIZ-6291 
 to this issue.
 compareBigDecimals scales down and rounds up meaning you lose information and 
 the comparison result is not as expected



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-6291:
--

What I have found is the cast to BigDecimal is fastest only if the object being 
cast is always BigDecimal, casting another object (eg java.lang.String) without 
type check (eg, catching and ignoring ClassCastException) is much slower. But 
these are in the nanosecond range of performance, hardly an argument to use one 
method or another. I just think it would be better to check for types rather 
than throwing an uncaught exception and not doing anything

I appreciate all committers are busy with life, work or other. This is a 
trivial issue, I don't believe this will have any functional impact, its just 
an improvement in code readability and follows better practices.

I still have reservations about compareBigDecimals but this is another issue to 
discuss somewhere else



 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: LocalizedConverters.patch, minilang_compare.patch, 
 minilang_compare_r1675655.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)