[jira] [Commented] (OFBIZ-9338) Several file names do not adhere to conventions applied to same files in other components

2017-07-01 Thread Pierre Smits (JIRA)

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

Pierre Smits commented on OFBIZ-9338:
-

Thanks [~mbrohl].

> Several file names do not adhere to conventions applied to same files in 
> other components
> -
>
> Key: OFBIZ-9338
> URL: https://issues.apache.org/jira/browse/OFBIZ-9338
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting, content, order, product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Michael Brohl
>Priority: Trivial
>
> In accounting
> DemoAccountingUserData.xml -> AccountingUserDemoData.xml
> DemoAcctgTransactionData.xml -> AcctgTransactionDemoData.xml
> DemoAssetMaintData.ml -> AssetMaintDemoData.xml
> DemoBudgetData.xml -> BudgetDemoData.xml
> DemoFinAccountData.xml -> FinAccountDemoData.xml
> DemoGeneralChartOfAccounts.xml -> GeneralChartofAccountsDemoData.xml
> DemoGlSetupData.xml -> GlSetupDemoData.xml
> DemoOrganisationData.xml -> OrganisationDemoData.xml
> DemoPaymentsInvoices.xml -> InvoicePaymentsDemoData.xml
> DemoStandardCosting.xml -> StandardCostingDemoData.xml
> DemoTaxAuthority.xml -> TaxAuthorityDemoData.xml
> UsTaxAccountsGroups.xml -> UsTaxAccountGroupDemoData.xml
> in content:
> DemoBlogEntryData.xml -> BlogEntryDemoData.xml
> DemoBlogPubPtData.xml -> BlogPubPtDemoData.xml
> DemoBlogUsersData.xml -> BlogUsersDemoData.xml
> in product:
> ApiSchemaDhl.xml -> DhlApiSchemaDemoData.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-9444) Dependency problem between Solr 6.6.0 and Guava

2017-07-01 Thread Michael Brohl (JIRA)

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

Michael Brohl commented on OFBIZ-9444:
--

I was able to successfully run the tests with the following configuration in 
the main build.gradle file:

{code:java}
configurations.all {
resolutionStrategy {
  // force certain versions of dependencies (including transitive)
  //  *append new forced modules:
  force 'com.google.guava:guava:20.0'
  //  *replace existing forced modules with new ones:
  forcedModules = ['com.google.guava:guava:20.0']
}
}
{code}

The Guava 22 files are not loaded by Cradle then.

The tests fail if I put this configuration in the Solr plugin build.gradle 
file. The Guava 22 version is loaded and the tests fail.

I know that this is not an acceptable solution because it introduces 
dependencies (or configurations) for a plugin in the base project.

Any hints how to force a certain dependency version using the child project 
build file instead of the main build file?

> Dependency problem between Solr 6.6.0 and Guava
> ---
>
> Key: OFBIZ-9444
> URL: https://issues.apache.org/jira/browse/OFBIZ-9444
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: solr
>Affects Versions: Trunk
>Reporter: Michael Brohl
> Attachments: dependencies.txt
>
>
> It seems we have a dependency problem in our codebase.
> The Solr code needs access to a method 
> com.google.common.base.Objects.firstNonNull, which was removed from Guava 
> from version 21 (see [1]).
> I tried to add the dependency both through the Solr build.gradle with
> {code:java}
> dependencies {
> pluginLibsCompile 'org.apache.solr:solr-core:6.6.0'
> pluginLibsCompile 'com.google.guava:guava:20.0'
> }
> {code}
> and also as a runtime dependency in main build.gradle
> {code:java}
> dependencies {
> // ofbiz compile libs
> ...
> runtime 'com.google.guava:guava:20.0'
> ...
> }
> {code}
> Both did not work. Running my Solo tests I get the error
> {code:java}
> 2017-07-01 14:25:18,049 |jsse-nio-8443-exec-4 |HttpSolrCall  
> |E| null:java.lang.RuntimeException: java.lang.NoSuchMethodError: 
> com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
> at 
> org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:676)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:544)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.apache.ofbiz.solr.webapp.OFBizSolrContextFilter.doFilter(OFBizSolrContextFilter.java:151)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at 
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
> at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
> at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
> at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> 

[jira] [Updated] (OFBIZ-9444) Dependency problem between Solr 6.6.0 and Guava

2017-07-01 Thread Michael Brohl (JIRA)

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

Michael Brohl updated OFBIZ-9444:
-
Attachment: dependencies.txt

I'll attach the current dependencies here. If I see it right, nothing depends 
on Guava > 20, but 22 seems to be pulled everywhere.

Maybe someone has a hint how to restrict the build/runtime to Guava 20?

> Dependency problem between Solr 6.6.0 and Guava
> ---
>
> Key: OFBIZ-9444
> URL: https://issues.apache.org/jira/browse/OFBIZ-9444
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: solr
>Affects Versions: Trunk
>Reporter: Michael Brohl
> Attachments: dependencies.txt
>
>
> It seems we have a dependency problem in our codebase.
> The Solr code needs access to a method 
> com.google.common.base.Objects.firstNonNull, which was removed from Guava 
> from version 21 (see [1]).
> I tried to add the dependency both through the Solr build.gradle with
> {code:java}
> dependencies {
> pluginLibsCompile 'org.apache.solr:solr-core:6.6.0'
> pluginLibsCompile 'com.google.guava:guava:20.0'
> }
> {code}
> and also as a runtime dependency in main build.gradle
> {code:java}
> dependencies {
> // ofbiz compile libs
> ...
> runtime 'com.google.guava:guava:20.0'
> ...
> }
> {code}
> Both did not work. Running my Solo tests I get the error
> {code:java}
> 2017-07-01 14:25:18,049 |jsse-nio-8443-exec-4 |HttpSolrCall  
> |E| null:java.lang.RuntimeException: java.lang.NoSuchMethodError: 
> com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
> at 
> org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:676)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:544)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.apache.ofbiz.solr.webapp.OFBizSolrContextFilter.doFilter(OFBizSolrContextFilter.java:151)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at 
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
> at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
> at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
> at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoSuchMethodError: 
> com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
> at 
> org.apache.solr.handler.component.HighlightComponent.prepare(HighlightComponent.java:118)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:270)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at 

[jira] [Commented] (OFBIZ-9443) Missing port.https configuration value breaks Solr

2017-07-01 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-9443:


Hi Michael, I guess you refer to 
http://svn.apache.org/viewvc?view=revision=1784930. I fear putting 
back a default value here will create some issues, at least on demos. Even if 
at the moment OFBIZ-9240 still needs to be resolved.

About
bq. This breaks the Solr functionality because it reads the ports for 
http/https from this file.
Actually only the default value for port.https has been removed because (as 
explained in the commit comment) the WebSiteProperties class "reuse the port 
initially found in the 1st login URL" and this has side effects when loging 
in/out. All this is initially related with HTTPS and HSTS.

I suggest to use this patch with default values, as it existed for HTTPS before 
r1784930 (HTTP port value did not change).
{code}
Index: plugins/solr/src/main/java/org/apache/ofbiz/solr/SolrUtil.java
===
--- plugins/solr/src/main/java/org/apache/ofbiz/solr/SolrUtil.java  
(revision 1795779)
+++ plugins/solr/src/main/java/org/apache/ofbiz/solr/SolrUtil.java  
(working copy)
 /**
  * Solr utility class.
@@ -85,7 +85,7 @@
 if (UtilValidate.isNotEmpty(solrWebappPortOverride)) {
 solrPort = solrWebappPortOverride;
 } else {
-solrPort = UtilProperties.getPropertyValue("url", 
("https".equals(solrWebappProtocol) ? "port.https" : "port.http"));
+solrPort = UtilProperties.getPropertyValue("url", 
("https".equals(solrWebappProtocol) ? "port.https" : "port.http"), 
("https".equals(solrWebappProtocol) ? "8443" : "8080"));
 }
 
 return solrWebappProtocol + "://" + solrWebappDomainName + ":" + 
solrPort + solrWebappPath;
{code}



> Missing port.https configuration value breaks Solr
> --
>
> Key: OFBIZ-9443
> URL: https://issues.apache.org/jira/browse/OFBIZ-9443
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework, solr
>Affects Versions: Trunk
>Reporter: Michael Brohl
>
> Following OFBIZ-9206 the port.https value was removed from the configuration. 
> This breaks the Solr functionality because it reads the ports for http/https 
> from this file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (OFBIZ-9444) Dependency problem between Solr 6.6.0 and Guava

2017-07-01 Thread Michael Brohl (JIRA)

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

Michael Brohl updated OFBIZ-9444:
-
Description: 
It seems we have a dependency problem in our codebase.

The Solr code needs access to a method 
com.google.common.base.Objects.firstNonNull, which was removed from Guava from 
version 21 (see [1]).

I tried to add the dependency both through the Solr build.gradle with

{code:java}
dependencies {
pluginLibsCompile 'org.apache.solr:solr-core:6.6.0'
pluginLibsCompile 'com.google.guava:guava:20.0'
}
{code}

and also as a runtime dependency in main build.gradle

{code:java}
dependencies {
// ofbiz compile libs
...
runtime 'com.google.guava:guava:20.0'
...
}
{code}

Both did not work. Running my Solo tests I get the error

{code:java}
2017-07-01 14:25:18,049 |jsse-nio-8443-exec-4 |HttpSolrCall  
|E| null:java.lang.RuntimeException: java.lang.NoSuchMethodError: 
com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
at org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:676)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:544)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
at 
org.apache.ofbiz.solr.webapp.OFBizSolrContextFilter.doFilter(OFBizSolrContextFilter.java:151)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoSuchMethodError: 
com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
at 
org.apache.solr.handler.component.HighlightComponent.prepare(HighlightComponent.java:118)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:270)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
... 25 more
{code}

After removing my grade cache and doing a fresh

{code:java}
./gradlew cleanAll loadAll testIntegration
{code}

the cradle cache contains both libraries from Guava 20.0 and 22.0 so I guess 
there must be some other dependency somewhere.

[1] https://issues.apache.org/jira/browse/SOLR-10308

  was:
It seems we have a dependency problem in our codebase.

The Solr code needs access to a method 
com.google.common.base.Objects.firstNonNull, which was removed from Guava from 
version 21 (see [1]).

I tried to add the dependency both through the Solr build.gradle with

{code:java}
dependencies {
pluginLibsCompile 'org.apache.solr:solr-core:6.6.0'
pluginLibsCompile 

[jira] [Created] (OFBIZ-9444) Dependency problem between Solr 6.6.0 and Guava

2017-07-01 Thread Michael Brohl (JIRA)
Michael Brohl created OFBIZ-9444:


 Summary: Dependency problem between Solr 6.6.0 and Guava
 Key: OFBIZ-9444
 URL: https://issues.apache.org/jira/browse/OFBIZ-9444
 Project: OFBiz
  Issue Type: Sub-task
  Components: solr
Affects Versions: Trunk
Reporter: Michael Brohl


It seems we have a dependency problem in our codebase.

The Solr code needs access to a method 
com.google.common.base.Objects.firstNonNull, which was removed from Guava from 
version 21 (see [1]).

I tried to add the dependency both through the Solr build.gradle with

{code:java}
dependencies {
pluginLibsCompile 'org.apache.solr:solr-core:6.6.0'
pluginLibsCompile 'com.google.guava:guava:20.0'
}
{code}

and also as a runtime dependency in main build.gradle

{code:java}
dependencies {
// ofbiz compile libs
...
runtime 'com.google.guava:guava:20.0'
...
}
{code}

Both did not work. Running my Solo tests I get the error

{code:java}
2017-07-01 14:25:18,049 |jsse-nio-8443-exec-4 |HttpSolrCall  
|E| null:java.lang.RuntimeException: java.lang.NoSuchMethodError: 
com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
at org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:676)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:544)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
at 
org.apache.ofbiz.solr.webapp.OFBizSolrContextFilter.doFilter(OFBizSolrContextFilter.java:151)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:156)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoSuchMethodError: 
com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
at 
org.apache.solr.handler.component.HighlightComponent.prepare(HighlightComponent.java:118)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:270)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
... 25 more
{code}

After removing my grade cache and doing a fresh

{code:java}
./gradlew cleanAll loadAll testIntegration
{code}

the cradle cache contains both libraries from Guava 20.0 and 22.0 so I guess 
there must be some other dependency somewhere.

[1] 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-9369) Add order priority management on sale order creation

2017-07-01 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-9369:


Hi,

Looking for more information about priority I stumbled upon this comment, in 
InventoryServices.xml, which is worth considering (with related code) in this 
issue.

{code}
 
{code}



> Add order priority management on sale order creation
> 
>
> Key: OFBIZ-9369
> URL: https://issues.apache.org/jira/browse/OFBIZ-9369
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Leila Mekika
>Priority: Minor
> Attachments: OFBIZ-9369.patch
>
>
> I made a patch to allow order priority setting when creating sale order.
> This add option on order first step creation an add it to the OrderHeader 
> during creation so that reservation SECA is triggered.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)