[jira] [Commented] (OFBIZ-10592) OutOfMemory and stucked JobPoller issue

2018-10-13 Thread Shi Jinghai (JIRA)


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

Shi Jinghai commented on OFBIZ-10592:
-

Thank you Giulio for the details!

I think you can resolve this problem by changing the implement of 
autoDeleteAutoSaveShoppingList to use queryPagedList instead of queryList, 
adding offset-style="limit" to your mariadb datasource in entityengine.xml.

Hope your patch soon :)

> OutOfMemory and stucked JobPoller issue
> ---
>
> Key: OFBIZ-10592
> URL: https://issues.apache.org/jira/browse/OFBIZ-10592
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS
>Affects Versions: Release Branch 13.07
> Environment: Two instances Ofbiz installation on two machines, 
> connected to an Apache HTTPD instance which acts as a proxy.
> Request to ofbiz instances are handled and load balanced.
> OFBiz version : 13.07.03 with Multitenant enabled
> OS: Ubuntu Linux 16.04 LTS
> RDBMS: MariaDB v10.1.24
>Reporter: Giulio Speri
>Assignee: Giulio Speri
>Priority: Critical
> Attachments: alloc_tree_600k_12102018.png, 
> jvm_ofbiz1_profi_telem.png, jvm_prof_ofbiz1_telem2.png, 
> ofbiz1_jvm_profil_nojobpoller.png, recorder_object_600k_12102018.png, 
> telemetry_ovrl_600k_12102018.png
>
>
>  
> This installation is composed by two instances of OFBiz (v13.07.03), served 
> via an Apache Tomcat webserver, along with a load balancer.
> The database server is MariaDB.
>  
> We had the first problems, about 3 weeks ago, when suddenly, the front1 
> (ofbiz instance 1), stopped serving web requests; front2, instead, was still 
> working correctly.
>  
> Obviously we checked the log files, and we saw that async services were 
> failing; the failure was accompanied by this error line:
>  
> *_Thread "AsyncAppender-async" java.lang.OutOfMemoryError: GC overhead limit 
> exceeded_*
>  
> We analyzed the situation with our system specialists, and they told us that 
> the application was highly stressing machine resources (cpu always at or near 
> 100%, RAM usage rapidly increasing), until the jvm run out of memory.
> This "resource-high-consumption situation", occurred only when ofbiz1 
> instance was started with the JobPoller enabled; if the JobPoller was not 
> enabled, ofbiz run with low resource usage. 
>  
> We then focused on the db, to check first of all the dimensions; the result 
> was disconcerting; 45GB, mainly divided on four tables: SERVER_HIT (about 18 
> GB), VISIT (about 15 GB), ENTITY_SYNC_REMOVE (about 8 GB), VISITOR (about 2 
> GB).
> All the other tables had a size in the order of few MB each.
>  
> The first thing we did, was to clear all those tables, reducing considerably 
> the db size.
> After the cleaning, we tried to start ofbiz1 again, with the JobPoller 
> component enabled; this caused a lot of old scheduled/queued jobs, to execute.
> Except than for the start-up time, the resource usage of the machine, 
> stabilized around normal to low values (cpu 1-10%).
> Ofbiz seemed to work (web request was served), but we noticed taht the 
> JobPoller did not schedule or run jobs, anymore. 
> The number of job in "Pending" state in the JobSandbox entity was small 
> (about 20); no Queued, no Failed, no jobs in other states.
> In addition to this, unfortunately, after few hours, jvm run out of memory 
> again.
>  
> Our jvm has an heap maximum size of 20GB ( we have 32GB on the  machine), so 
> it's not so small, I think.
> The next step we're going to do is set-up locally the application over the 
> same production db to see what happens.
>  
> Now that I explained the situation, I am going to ask if, in your 
> opinion/experience:
>  
> Could the JobPoller component be the root (and only) cause of the OutOfMemory 
> of the jvm?
>  
> Could this issue be related to OFBIZ-5710?
>  
> Dumping and analyzing the heap of the jvm could help in some way to 
> understand what or who fills the memory or is this operation a waste of time?
>  
> Is there something that we did not considered or missed during the whole 
> process of problem analysis?
>  
>  
> I really thank you all for your attention and your help; any suggestion or 
> advice would really be greatly appreciated.
>  
> Kind regards,
> Giulio



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OFBIZ-10604) Isolate EntityOperator and EntityConditionValue from EntityConditionBase

2018-10-13 Thread Gil Portenseigne (JIRA)


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

Gil Portenseigne updated OFBIZ-10604:
-
Description: 
While working on OFBIZ-10593 with [~mthl] we discovered a design issue around 
{{EntityConditionBase}} inheritence.
 Indeed {{EntityOperator}} and {{EntityConditionValue}} inherits from 
{{EntityConditionBase}}, even if they can't be considered as proper "entity 
conditions". 

It should be determined what was the need behind this inheritance and refactor 
it to isolate that classes that do not appear to be "entity conditions".

  was:
While working on OFBIZ-10593 with [~mthl] we discovered a design issue around 
{{EntityConditionBase}} inheritence.
 Indeed {{EntityOperator}} and {{EntityConditionValue}} inherits from 
{{EntityConditionBase}}, even if they can't be considered as proper "entity 
conditions". 
 It should be determined what was the need behind this inheritance and refactor 
it to isolate that classes that do not appear to be "entity conditions".


> Isolate EntityOperator and EntityConditionValue from EntityConditionBase 
> -
>
> Key: OFBIZ-10604
> URL: https://issues.apache.org/jira/browse/OFBIZ-10604
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
>
> While working on OFBIZ-10593 with [~mthl] we discovered a design issue around 
> {{EntityConditionBase}} inheritence.
>  Indeed {{EntityOperator}} and {{EntityConditionValue}} inherits from 
> {{EntityConditionBase}}, even if they can't be considered as proper "entity 
> conditions". 
> It should be determined what was the need behind this inheritance and 
> refactor it to isolate that classes that do not appear to be "entity 
> conditions".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (OFBIZ-10604) Isolate EntityOperator and EntityConditionValue from EntityConditionBase

2018-10-13 Thread Gil Portenseigne (JIRA)
Gil Portenseigne created OFBIZ-10604:


 Summary: Isolate EntityOperator and EntityConditionValue from 
EntityConditionBase 
 Key: OFBIZ-10604
 URL: https://issues.apache.org/jira/browse/OFBIZ-10604
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


While working on OFBIZ-10593 with [~mthl] we discovered a design issue around 
{{EntityConditionBase}} inheritence.
 Indeed {{EntityOperator}} and {{EntityConditionValue}} inherits from 
{{EntityConditionBase}}, even if they can't be considered as proper "entity 
conditions". 
 It should be determined what was the need behind this inheritance and refactor 
it to isolate that classes that do not appear to be "entity conditions".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OFBIZ-10593) ‘EntityConditionVisitor’ is a confused visitor pattern

2018-10-13 Thread Gil Portenseigne (JIRA)


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

Gil Portenseigne closed OFBIZ-10593.


> ‘EntityConditionVisitor’ is a confused visitor pattern
> --
>
> Key: OFBIZ-10593
> URL: https://issues.apache.org/jira/browse/OFBIZ-10593
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments: 
> OFBIZ-10593_Implement-EntityConditionVisitor-properly.patch
>
>
> {{EntityConditionVisitor}} interface is supposed to implement the visitor 
> pattern which supposes a set of classes meant to be visited using an 
> {{accept}} method and a visitor with multiple {{visit}} method overloads (one 
> for each visited class).
> Currently {{EntityConditionVisitor}} contains both {{accept}} and {{visit}} 
> methods which make *no sense*
> {code:java}
> public interface EntityConditionVisitor {
>  void visit(T obj);
>  void accept(T obj);
> void acceptObject(Object obj);
> void acceptEntityCondition(EntityCondition condition);
>  void 
> acceptEntityJoinOperator(EntityJoinOperator op, List conditions);
>  void acceptEntityOperator(EntityOperator op, L lhs, R 
> rhs);
>  void acceptEntityComparisonOperator(EntityComparisonOperator 
> op, L lhs, R rhs);
> void acceptEntityConditionValue(EntityConditionValue value);
> void acceptEntityFieldValue(EntityFieldValue value);
> void acceptEntityExpr(EntityExpr expr);
>  void 
> acceptEntityConditionList(EntityConditionList list);
> void acceptEntityFieldMap(EntityFieldMap fieldMap);
> void acceptEntityConditionFunction(EntityConditionFunction func, 
> EntityCondition nested);
> > void acceptEntityFunction(EntityFunction 
> func);
> void acceptEntityWhereString(EntityWhereString condition);
> void acceptEntityDateFilterCondition(EntityDateFilterCondition condition);
> }
> {code}
> this confusion is visible in the {{EntityCondition}} which has both a 
> {{visit}} and an {{accept}} method, even if it is only supposed to accept a 
> visitor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OFBIZ-10603) Javadoc doesn't contains links to external documentation

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin commented on OFBIZ-10603:


I have provided [^OFBIZ-10603_Provide-external-links-in-Javadoc.patch] 
configuring the {{javadoc}} Gradle plugin with some important dependencies.

> Javadoc doesn't contains links to external documentation
> 
>
> Key: OFBIZ-10603
> URL: https://issues.apache.org/jira/browse/OFBIZ-10603
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10603_Provide-external-links-in-Javadoc.patch
>
>
> While reading the OFBiz javadoc, it is often necessary to look at OFBiz 
> dependencies documentation to properly understand it.  Currently this has to 
> be done manually.  It would be convenient to be able to click and on class 
> definition of a dependency to go to its documentation.  This can be done via 
> the {{-link}} option of {{javadoc}} command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OFBIZ-10603) Javadoc doesn't contains links to external documentation

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin updated OFBIZ-10603:
---
Attachment: OFBIZ-10603_Provide-external-links-in-Javadoc.patch

> Javadoc doesn't contains links to external documentation
> 
>
> Key: OFBIZ-10603
> URL: https://issues.apache.org/jira/browse/OFBIZ-10603
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10603_Provide-external-links-in-Javadoc.patch
>
>
> While reading the OFBiz javadoc, it is often necessary to look at OFBiz 
> dependencies documentation to properly understand it.  Currently this has to 
> be done manually.  It would be convenient to be able to click and on class 
> definition of a dependency to go to its documentation.  This can be done via 
> the {{-link}} option of {{javadoc}} command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (OFBIZ-10603) Javadoc doesn't contains links to external documentation

2018-10-13 Thread Mathieu Lirzin (JIRA)
Mathieu Lirzin created OFBIZ-10603:
--

 Summary: Javadoc doesn't contains links to external documentation
 Key: OFBIZ-10603
 URL: https://issues.apache.org/jira/browse/OFBIZ-10603
 Project: OFBiz
  Issue Type: Improvement
Affects Versions: Trunk
Reporter: Mathieu Lirzin
 Fix For: Upcoming Branch


While reading the OFBiz javadoc, it is often necessary to look at OFBiz 
dependencies documentation to properly understand it.  Currently this has to be 
done manually.  It would be convenient to be able to click and on class 
definition of a dependency to go to its documentation.  This can be done via 
the {{-link}} option of {{javadoc}} command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (OFBIZ-7775) Cleanup JavaDocs to be standards compliant

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin edited comment on OFBIZ-7775 at 10/13/18 6:21 PM:
-

Hello,

I have provided 
[^OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch] which 
removes some javadoc warnings.  This is done by removing some redundant javadoc 
comments that are already well written in the implemented interface.


was (Author: mthl):
Hello,

I have provided a 
[^OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch] which 
removes some javadoc warnings.  This is done by removing some redundant javadoc 
comments that are already well written in the implemented interface.

> Cleanup JavaDocs to be standards compliant
> --
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: 
> OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch
>
>
> To check what to fix simply run gradlew javadoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OFBIZ-7775) Cleanup JavaDocs to be standards compliant

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin commented on OFBIZ-7775:
---

Hello,

I have provided a 
[^OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch] which 
removes some javadoc warnings.  This is done by removing some redundant javadoc 
comments that are already well written in the implemented interface.

> Cleanup JavaDocs to be standards compliant
> --
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: 
> OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch
>
>
> To check what to fix simply run gradlew javadoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OFBIZ-7775) Cleanup JavaDocs to be standards compliant

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin updated OFBIZ-7775:
--
Attachment: OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch

> Cleanup JavaDocs to be standards compliant
> --
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: 
> OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch
>
>
> To check what to fix simply run gradlew javadoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OFBIZ-7775) Cleanup JavaDocs to be standards compliant

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin updated OFBIZ-7775:
--
Attachment: OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch

> Cleanup JavaDocs to be standards compliant
> --
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: 
> OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch
>
>
> To check what to fix simply run gradlew javadoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OFBIZ-7775) Cleanup JavaDocs to be standards compliant

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin updated OFBIZ-7775:
--
Attachment: (was: 
OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch)

> Cleanup JavaDocs to be standards compliant
> --
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: 
> OFBIZ-7775_Remove-useless-overidden-JavaMailContainer-jav.patch
>
>
> To check what to fix simply run gradlew javadoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OFBIZ-10602) Refactor ICalendar support

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin updated OFBIZ-10602:
---
Attachment: OFBIZ-10602_Refactor-ICalendar-support.patch

> Refactor ICalendar support
> --
>
> Key: OFBIZ-10602
> URL: https://issues.apache.org/jira/browse/OFBIZ-10602
> Project: OFBiz
>  Issue Type: Improvement
>  Components: workeffort
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10602_Refactor-ICalendar-support.patch
>
>
> Here is a some small improvement of the documentation and implementation of 
> the ICalendar support.
> Rewrite documentation to remove Javadoc warnings and improve implementation 
> by avoiding classes with only one method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (OFBIZ-10602) Refactor ICalendar support

2018-10-13 Thread Mathieu Lirzin (JIRA)
Mathieu Lirzin created OFBIZ-10602:
--

 Summary: Refactor ICalendar support
 Key: OFBIZ-10602
 URL: https://issues.apache.org/jira/browse/OFBIZ-10602
 Project: OFBiz
  Issue Type: Improvement
  Components: workeffort
Affects Versions: Trunk
Reporter: Mathieu Lirzin
 Fix For: Upcoming Branch


Here is a some small improvement of the documentation and implementation of the 
ICalendar support.

Rewrite documentation to remove Javadoc warnings and improve implementation by 
avoiding classes with only one method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OFBIZ-10598) Add an ofbizsetup to the data files names used by the ofbizsetup app

2018-10-13 Thread Rishi Solanki (JIRA)


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

Rishi Solanki commented on OFBIZ-10598:
---

[~jacques.le.roux]

I gone thru the code in the SetupEvents.xml and found that some other files 
missing used in the code like DemoGeneralChartOfAccounts.xml which was renamed 
as GlSetupDemoData.xml in commit r1800303 and then moved by me to datamodel 
component in r1823177.

So in this effort we may need to check the missing files if any to make the 
services works again. I'll upload the patch soon for this.

> Add an ofbizsetup to the data files names used by the ofbizsetup app
> 
>
> Key: OFBIZ-10598
> URL: https://issues.apache.org/jira/browse/OFBIZ-10598
> Project: OFBiz
>  Issue Type: Improvement
>  Components: commonext
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> This follows the ["Shipping data 
> duplicated"|https://markmail.org/message/m3l7z3okir3u3gx2] discussion in dev 
> ML.
> The idea is to add an ofbizsetup prefix to the data files names used by the 
> ofbizsetup app in order to not confuse them and their content with other same 
> data in demo files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OFBIZ-10593) ‘EntityConditionVisitor’ is a confused visitor pattern

2018-10-13 Thread Mathieu Lirzin (JIRA)


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

Mathieu Lirzin commented on OFBIZ-10593:


Hello Gil,

I fully agree on creating an issue for isolating {{EntityOperator}} and 
{{EntityConditionValue}} from {{EntityConditionBase}}.  Please go ahead.

Thanks for the review!

> ‘EntityConditionVisitor’ is a confused visitor pattern
> --
>
> Key: OFBIZ-10593
> URL: https://issues.apache.org/jira/browse/OFBIZ-10593
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Gil Portenseigne
>Priority: Major
> Attachments: 
> OFBIZ-10593_Implement-EntityConditionVisitor-properly.patch
>
>
> {{EntityConditionVisitor}} interface is supposed to implement the visitor 
> pattern which supposes a set of classes meant to be visited using an 
> {{accept}} method and a visitor with multiple {{visit}} method overloads (one 
> for each visited class).
> Currently {{EntityConditionVisitor}} contains both {{accept}} and {{visit}} 
> methods which make *no sense*
> {code:java}
> public interface EntityConditionVisitor {
>  void visit(T obj);
>  void accept(T obj);
> void acceptObject(Object obj);
> void acceptEntityCondition(EntityCondition condition);
>  void 
> acceptEntityJoinOperator(EntityJoinOperator op, List conditions);
>  void acceptEntityOperator(EntityOperator op, L lhs, R 
> rhs);
>  void acceptEntityComparisonOperator(EntityComparisonOperator 
> op, L lhs, R rhs);
> void acceptEntityConditionValue(EntityConditionValue value);
> void acceptEntityFieldValue(EntityFieldValue value);
> void acceptEntityExpr(EntityExpr expr);
>  void 
> acceptEntityConditionList(EntityConditionList list);
> void acceptEntityFieldMap(EntityFieldMap fieldMap);
> void acceptEntityConditionFunction(EntityConditionFunction func, 
> EntityCondition nested);
> > void acceptEntityFunction(EntityFunction 
> func);
> void acceptEntityWhereString(EntityWhereString condition);
> void acceptEntityDateFilterCondition(EntityDateFilterCondition condition);
> }
> {code}
> this confusion is visible in the {{EntityCondition}} which has both a 
> {{visit}} and an {{accept}} method, even if it is only supposed to accept a 
> visitor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)