buildbot failure in on ofbiz-branch13

[buildbot]

The Buildbot has detected a new failure on builder ofbiz-branch13 while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-branch13/builds/95

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz13-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release13.07] 1736092
Blamelist: jleroux

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot

[jira] [Commented] (OFBIZ-6776) Amount to capture for order is in-correct after manual refund electronic transaction

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6776:


Checking this, I need a commit in R15 to test INFRA-5

> Amount to capture for order is in-correct after manual refund electronic 
> transaction
> 
>
> Key: OFBIZ-6776
> URL: https://issues.apache.org/jira/browse/OFBIZ-6776
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting, order
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Nameet
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6776.patch, OFBIZ-6776.patch
>
>
> Steps to regenerate-
> 1) Place a sales order of Rainbow Gizmo. Order Total was of $29.91. Order 
> will be in approved status and in *Payment Information* section you will see 
> $29.91 as authorized and available to capture. 
> 2) Capture $15.00 by using the capture button available in *Payment 
> Information* block. System should successfully captured $15.00 and also new 
> authorized payment of $14.91 should be seen in Payment Information section.
> 3) Refund $5.00, for that use manual electronic transfer UI in accounting. 
> System successfully does the refund.
> 4) Click quick ship entire order from order screen. As per payment 
> requirement, now system should proceed to complete the capture process for 
> amount $19.91($29.91 - $15(Captured) + $5(Refunded)) but it captures only 
> $9.91 and not showing any remaining amount to capture on order. Also the 
> order invoice due shows $0.00.
> Possible reason of the issue is that manual refund payment amount is being 
> considered by the system as received payment and hence amount to capture on 
> order is calculated wrong.



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

[jira] [Assigned] (OFBIZ-6776) Amount to capture for order is in-correct after manual refund electronic transaction

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux reassigned OFBIZ-6776:
--

Assignee: Jacques Le Roux  (was: Pranay Pandey)

> Amount to capture for order is in-correct after manual refund electronic 
> transaction
> 
>
> Key: OFBIZ-6776
> URL: https://issues.apache.org/jira/browse/OFBIZ-6776
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting, order
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk
>Reporter: Nameet
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6776.patch, OFBIZ-6776.patch
>
>
> Steps to regenerate-
> 1) Place a sales order of Rainbow Gizmo. Order Total was of $29.91. Order 
> will be in approved status and in *Payment Information* section you will see 
> $29.91 as authorized and available to capture. 
> 2) Capture $15.00 by using the capture button available in *Payment 
> Information* block. System should successfully captured $15.00 and also new 
> authorized payment of $14.91 should be seen in Payment Information section.
> 3) Refund $5.00, for that use manual electronic transfer UI in accounting. 
> System successfully does the refund.
> 4) Click quick ship entire order from order screen. As per payment 
> requirement, now system should proceed to complete the capture process for 
> amount $19.91($29.91 - $15(Captured) + $5(Refunded)) but it captures only 
> $9.91 and not showing any remaining amount to capture on order. Also the 
> order invoice due shows $0.00.
> Possible reason of the issue is that manual refund payment amount is being 
> considered by the system as received payment and hence amount to capture on 
> order is calculated wrong.



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

[jira] [Updated] (OFBIZ-6568) Update Groovy to 2.4.5 version

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6568:
---
Fix Version/s: (was: Upcoming Branch)

> Update Groovy to 2.4.5 version
> --
>
> Key: OFBIZ-6568
> URL: https://issues.apache.org/jira/browse/OFBIZ-6568
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Jacques Le Roux
>Assignee: Jacopo Cappellato
> Fix For: 14.12.01, 12.04.06, 13.07.03, 15.12.01
>
>
> Since it's a security fix we should also update all  supported releases 
> branches. http://groovy-lang.org/security.html



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

[jira] [Updated] (OFBIZ-6860) ProductSearch generates an errorr

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6860:
---
Fix Version/s: (was: Upcoming Branch)
   15.12.01

> ProductSearch generates an errorr
> -
>
> Key: OFBIZ-6860
> URL: https://issues.apache.org/jira/browse/OFBIZ-6860
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Pierre Smits
>Assignee: Deepak Dixit
>  Labels: lucene, search
> Fix For: 15.12.01
>
>
> When executing a product search in the content application an error is thrown.
> In demo-trunk: 
> https://demo-trunk-ofbiz.apache.org/content/control/ProductSearch
> the following error is thrown:
> {code}
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
> [component://lucene/widget/LuceneScreens.xml#ProductSearch]: 
> java.lang.IllegalArgumentException: Error running script at location 
> [component://lucene/webapp/content/WEB-INF/actions/SearchProducts.groovy]: 
> groovy.lang.MissingMethodException: No signature of method: static 
> org.apache.lucene.store.FSDirectory.open() is applicable for argument types: 
> (java.io.File) values: [runtime/indexes/products] Possible solutions: 
> open(java.nio.file.Path), open(java.nio.file.Path, 
> org.apache.lucene.store.LockFactory), grep(), grep(java.lang.Object), 
> use([Ljava.lang.Object;), wait() (Error running script at location 
> [component://lucene/webapp/content/WEB-INF/actions/SearchProducts.groovy]: 
> groovy.lang.MissingMethodException: No signature of method: static 
> org.apache.lucene.store.FSDirectory.open() is applicable for argument types: 
> (java.io.File) values: [runtime/indexes/products] Possible solutions: 
> open(java.nio.file.Path), open(java.nio.file.Path, 
> org.apache.lucene.store.LockFactory), grep(), grep(java.lang.Object), 
> use([Ljava.lang.Object;), wait())
> {code}



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

[jira] [Updated] (OFBIZ-6943) Problem uploading data resource other than image in DB

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6943:
---
Fix Version/s: (was: Upcoming Branch)

> Problem uploading data resource other than image in DB
> --
>
> Key: OFBIZ-6943
> URL: https://issues.apache.org/jira/browse/OFBIZ-6943
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Fix For: 14.12.01, 15.12.01
>
>
> When in content.properties, content.upload.always.local.file is set to false, 
> uploading video, audio or other than image data is not possible.
> {quote}Failure in create operation for entity [OtherDataResource]: 
> org.ofbiz.entity.GenericEntityException: Error while inserting: 
> [GenericEntity:OtherDataResource][createdStamp,2016-03-19 
> 09:56:21.464(java.sql.Timestamp)][createdTxStamp,2016-03-19 
> 09:56:21.095(java.sql.Timestamp)][dataResourceContent,java.nio.HeapByteBuffer[pos=0
>  lim=1599972 
> cap=1599972](java.nio.HeapByteBuffer)][dataResourceId,1(java.lang.String)][lastUpdatedStamp,2016-03-19
>  09:56:21.464(java.sql.Timestamp)][lastUpdatedTxStamp,2016-03-19 
> 09:56:21.095(java.sql.Timestamp)] (SQL Exception while setting value on field 
> [dataResourceContent] of entity OtherDataResource:  
> (java.io.NotSerializableException: java.nio.HeapByteBuffer)). Rolling back 
> transaction.{quote}



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

[jira] [Updated] (OFBIZ-6894) Cannot find linkToProduct from createCommunicationEvent SECA

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6894:
---
Fix Version/s: (was: Upcoming Branch)

> Cannot find linkToProduct from createCommunicationEvent SECA 
> -
>
> Key: OFBIZ-6894
> URL: https://issues.apache.org/jira/browse/OFBIZ-6894
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/scrum
>Reporter: Jacques Le Roux
>Assignee: Deepak Dixit
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-6894.patch
>
>
> At r1596506 I had removed the createCommunicationEvent SECA because the 
> related tests (a lot) failed. Here is the stack trace:
> {code}
> 2016-02-14 13:07:36,013 |main |GenericDelegator  
> |E| Failure in findByCondition operation for entity [SystemProperty]: 
> org.ofbiz.entity.transaction.GenericTransactionException: The current 
> transaction is marked for rollback, not beginning a new transaction and 
> aborting current operation; the rollbackOnly was caused by: Service 
> [linkToProduct] threw an unexpected 
> exception/errororg.ofbiz.service.GenericServiceException: Cannot find service 
> [linkToProduct] location class (org.ofbiz.scrum.ScrumServices) (Cannot find 
> service [linkToProduct] location class (org.ofbiz.scrum.ScrumServices)). 
> Rolling back transaction.
> org.ofbiz.entity.transaction.GenericTransactionException: The current 
> transaction is marked for rollback, not beginning a new transaction and 
> aborting current operation; the rollbackOnly was caused by: Service 
> [linkToProduct] threw an unexpected 
> exception/errororg.ofbiz.service.GenericServiceException: Cannot find service 
> [linkToProduct] location class (org.ofbiz.scrum.ScrumServices) (Cannot find 
> service [linkToProduct] location class (org.ofbiz.scrum.ScrumServices))
>   at 
> org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:142) 
> ~[ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:110) 
> ~[ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.GenericDelegator.findList(GenericDelegator.java:1577) 
> [ofbiz-entity.jar:?]
>   at org.ofbiz.entity.util.EntityQuery.query(EntityQuery.java:454) 
> [ofbiz-entity.jar:?]
>   at org.ofbiz.entity.util.EntityQuery.queryList(EntityQuery.java:379) 
> [ofbiz-entity.jar:?]
>   at org.ofbiz.entity.util.EntityQuery.queryOne(EntityQuery.java:420) 
> [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.util.EntityUtilProperties.getSystemPropertyValue(EntityUtilProperties.java:61)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.util.EntityUtilProperties.getPropertyValue(EntityUtilProperties.java:88)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.common.email.EmailServices.sendMail(EmailServices.java:312) 
> [ofbiz-common.jar:?]
> [...]
> {code}



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

[jira] [Updated] (OFBIZ-6845) On the balance sheet, it display incorrect value on the total of long-term asset.

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6845:
---
Fix Version/s: (was: Upcoming Branch)

> On the balance sheet, it display incorrect value on the total of long-term 
> asset.
> -
>
> Key: OFBIZ-6845
> URL: https://issues.apache.org/jira/browse/OFBIZ-6845
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Supatthra Nawicha
> Fix For: 14.12.01, 15.12.01
>
> Attachments: addConditionForLongTermAsset.patch
>
>
> Now, it display the totals of all transactions of any assets. I have checked 
> on the code and I have found the missing condition checked in there. 
> {code:title=BalanceSheet.groovy|borderStyle=solid}
> List longtermAssetAndExprs = mainAndExprs as LinkedList;
> longtermAssetAndExprs.add(EntityCondition.makeCondition("glAccountClassId", 
> EntityOperator.IN, longtermAssetAccountClassIds));
> transactionTotals = select("glAccountId", "accountName", "accountCode", 
> "debitCreditFlag", 
> "amount").from("AcctgTransEntrySums").orderBy("glAccountId").queryList();
> {code}
> Actually, it should be:
> {code:java}
> List longtermAssetAndExprs = mainAndExprs as LinkedList;
> longtermAssetAndExprs.add(EntityCondition.makeCondition("glAccountClassId", 
> EntityOperator.IN, longtermAssetAccountClassIds));
> transactionTotals = select("glAccountId", "accountName", "accountCode", 
> "debitCreditFlag", 
> "amount").from("AcctgTransEntrySums").where(longtermAssetAndExprs).orderBy("glAccountId").queryList();
> {code}



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

[jira] [Commented] (OFBIZ-6942) Comment out RMI related code because of the Java deserialization issue

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6942:


Note: you don't need to revert the 1st set of commits

> Comment out RMI related code because of the Java deserialization issue
> --
>
> Key: OFBIZ-6942
> URL: https://issues.apache.org/jira/browse/OFBIZ-6942
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, 13.07.03, 15.12.01
>
>
> Because of the danger of Java deserialization when using RMI, we (PMC) have 
> decided to comment out RMI related code. I decided to comment out as less as 
> possible because once the RMI loaders, the RMI dispatcher and the related 
> test services are off there is no RMI related danger left (test services are 
> not a danger but would fail during tests run).  It's then easier for users 
> who need RMI in their projects to have only to uncomment those and not digg 
> everywhere. Because the naming (JNDI) server relies on the rmi loader it will 
> also be commented out.
> You can get more information in wiki page linked below in the "Issue Links" 
> section.



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

[jira] [Commented] (OFBIZ-6942) Comment out RMI related code because of the Java deserialization issue

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6942:


Done in 
trunk r1736083+r1736087
R15.12 r1736084+r1736088
R14.12 r1736085+r1736089
R13.07 r1736092



> Comment out RMI related code because of the Java deserialization issue
> --
>
> Key: OFBIZ-6942
> URL: https://issues.apache.org/jira/browse/OFBIZ-6942
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, 13.07.03, 15.12.01
>
>
> Because of the danger of Java deserialization when using RMI, we (PMC) have 
> decided to comment out RMI related code. I decided to comment out as less as 
> possible because once the RMI loaders, the RMI dispatcher and the related 
> test services are off there is no RMI related danger left (test services are 
> not a danger but would fail during tests run).  It's then easier for users 
> who need RMI in their projects to have only to uncomment those and not digg 
> everywhere. Because the naming (JNDI) server relies on the rmi loader it will 
> also be commented out.
> You can get more information in wiki page linked below in the "Issue Links" 
> section.



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

[jira] [Closed] (OFBIZ-6942) Comment out RMI related code because of the Java deserialization issue

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux closed OFBIZ-6942.
--
   Resolution: Fixed
Fix Version/s: (was: Upcoming Branch)
   15.12.01

> Comment out RMI related code because of the Java deserialization issue
> --
>
> Key: OFBIZ-6942
> URL: https://issues.apache.org/jira/browse/OFBIZ-6942
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, 13.07.03, 15.12.01
>
>
> Because of the danger of Java deserialization when using RMI, we (PMC) have 
> decided to comment out RMI related code. I decided to comment out as less as 
> possible because once the RMI loaders, the RMI dispatcher and the related 
> test services are off there is no RMI related danger left (test services are 
> not a danger but would fail during tests run).  It's then easier for users 
> who need RMI in their projects to have only to uncomment those and not digg 
> everywhere. Because the naming (JNDI) server relies on the rmi loader it will 
> also be commented out.
> You can get more information in wiki page linked below in the "Issue Links" 
> section.



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

Re: svn commit: r1736083 - in /ofbiz/trunk: framework/base/config/ofbiz-containers.xml framework/base/ofbiz-component.xml framework/service/ofbiz-component.xml framework/start/src/org/ofbiz/base/start

[Jacques Le Roux]

Damned, xpos.properties should not have been part of this, only both.properties 
(already in). I will remove it

Jacques

Le 21/03/2016 21:17, jler...@apache.org a écrit :

Author: jleroux
Date: Mon Mar 21 20:17:59 2016
New Revision: 1736083

URL: http://svn.apache.org/viewvc?rev=1736083=rev
Log:
This partially reverts r1735569 to simplify and have less commented out parts.

Fixes "Comment out RMI related code because of the Java deserialization issue" 
- https://issues.apache.org/jira/browse/OFBIZ-6942

We decided to comment out as less as possible because once, in the start and 
both properties; the rmi part is off and the related test services are off 
there is no RMI related danger left (test services are not a danger but would 
fail during tests run).
It's then easier for users who need RMI in their projects to have only to 
uncomment those and not digg everywhere.

Modified:
 ofbiz/trunk/framework/base/config/ofbiz-containers.xml
 ofbiz/trunk/framework/base/ofbiz-component.xml
 ofbiz/trunk/framework/service/ofbiz-component.xml
 ofbiz/trunk/framework/start/src/org/ofbiz/base/start/start.properties
 ofbiz/trunk/specialpurpose/pos/config/xpos.properties

Modified: ofbiz/trunk/framework/base/config/ofbiz-containers.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/config/ofbiz-containers.xml?rev=1736083=1736082=1736083=diff
==
--- ofbiz/trunk/framework/base/config/ofbiz-containers.xml (original)
+++ ofbiz/trunk/framework/base/config/ofbiz-containers.xml Mon Mar 21 20:17:59 
2016
@@ -21,11 +21,8 @@ under the License.
  http://www.w3.org/2001/XMLSchema-instance;
  
xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/ofbiz-containers.xsd;>
  
-
  
-
-
+
  
  

  

Modified: ofbiz/trunk/framework/base/ofbiz-component.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/ofbiz-component.xml?rev=1736083=1736082=1736083=diff
==
--- ofbiz/trunk/framework/base/ofbiz-component.xml (original)
+++ ofbiz/trunk/framework/base/ofbiz-component.xml Mon Mar 21 20:17:59 2016
@@ -33,13 +33,11 @@ under the License.
  
  
  
-
  
-
+
  
  

  

Modified: ofbiz/trunk/framework/service/ofbiz-component.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/service/ofbiz-component.xml?rev=1736083=1736082=1736083=diff
==
--- ofbiz/trunk/framework/service/ofbiz-component.xml (original)
+++ ofbiz/trunk/framework/service/ofbiz-component.xml Mon Mar 21 20:17:59 2016
@@ -44,17 +44,12 @@ under the License.
  
  
-
-
-
+
  
  
  
-
  
-
+
  
  

  
++#ofbiz.start.loader1.loaders=main,rmi
++ofbiz.start.loader1.loaders=main
+
  # -- Enable the shutdown hook
  #ofbiz.enable.hook=true
  


Modified: ofbiz/trunk/specialpurpose/pos/config/xpos.properties
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/pos/config/xpos.properties?rev=1736083=1736082=1736083=diff
==
--- ofbiz/trunk/specialpurpose/pos/config/xpos.properties (original)
+++ ofbiz/trunk/specialpurpose/pos/config/xpos.properties Mon Mar 21 20:17:59 
2016
@@ -1,35 +1,34 @@
  
###
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements.  See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership.  The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License.  You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied.  See the License for the
-# specific language governing permissions and limitations
-# under the License.
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# 

[jira] [Comment Edited] (OFBIZ-6942) Comment out RMI related code because of the Java deserialization issue

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux edited comment on OFBIZ-6942 at 3/21/16 8:19 PM:
-

This can be simpler as Jacopo explained on dev ML: 
http://markmail.org/message/dukv5glk3elilo5z


was (Author: jacques.le.roux):
This can be simpler as Jacopo explained

> Comment out RMI related code because of the Java deserialization issue
> --
>
> Key: OFBIZ-6942
> URL: https://issues.apache.org/jira/browse/OFBIZ-6942
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, 13.07.03, Upcoming Branch
>
>
> Because of the danger of Java deserialization when using RMI, we (PMC) have 
> decided to comment out RMI related code. I decided to comment out as less as 
> possible because once the RMI loaders, the RMI dispatcher and the related 
> test services are off there is no RMI related danger left (test services are 
> not a danger but would fail during tests run).  It's then easier for users 
> who need RMI in their projects to have only to uncomment those and not digg 
> everywhere. Because the naming (JNDI) server relies on the rmi loader it will 
> also be commented out.
> You can get more information in wiki page linked below in the "Issue Links" 
> section.



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

[jira] [Commented] (OFBIZ-6949) Week and day overview of calendar doesn't show entries

[Pierre Smits (JIRA)]

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

Pierre Smits commented on OFBIZ-6949:
-

All images provided are when the user is partyId 'BREWMASTER' with permissions 
WORKEFFORTMGR_VIEW and all calendar roles.

> Week  and day overview of calendar doesn't show entries
> ---
>
> Key: OFBIZ-6949
> URL: https://issues.apache.org/jira/browse/OFBIZ-6949
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: calendar, entry
> Attachments: Screen Shot 2016-03-21 at 20.00.17.png, Screen Shot 
> 2016-03-21 at 20.00.40.png, Screen Shot 2016-03-21 at 20.00.59.png
>
>
> In WorkEffort, the calendar overview the month overview shows all entries. 
> This not only applies to users with the WORKEFFORTMGR_ADMIN permission, but 
> also to users with the WORKEFFORTMGR_VIEW permission.
> However, when switching to the week view or or day view, the user with 
> permission WORKEFFORTMGR_VIEW permission doesn't see the entries for that 
> week or day view. While the user with permission WORKEFFORTMGR_ADMIN does.



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

[jira] [Updated] (OFBIZ-6949) Week and day overview of calendar doesn't show entries

[Pierre Smits (JIRA)]

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

Pierre Smits updated OFBIZ-6949:

Attachment: Screen Shot 2016-03-21 at 20.00.17.png
Screen Shot 2016-03-21 at 20.00.40.png
Screen Shot 2016-03-21 at 20.00.59.png

> Week  and day overview of calendar doesn't show entries
> ---
>
> Key: OFBIZ-6949
> URL: https://issues.apache.org/jira/browse/OFBIZ-6949
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: calendar, entry
> Attachments: Screen Shot 2016-03-21 at 20.00.17.png, Screen Shot 
> 2016-03-21 at 20.00.40.png, Screen Shot 2016-03-21 at 20.00.59.png
>
>
> In WorkEffort, the calendar overview the month overview shows all entries. 
> This not only applies to users with the WORKEFFORTMGR_ADMIN permission, but 
> also to users with the WORKEFFORTMGR_VIEW permission.
> However, when switching to the week view or or day view, the user with 
> permission WORKEFFORTMGR_VIEW permission doesn't see the entries for that 
> week or day view. While the user with permission WORKEFFORTMGR_ADMIN does.



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

[jira] [Created] (OFBIZ-6949) Week and day overview of calendar doesn't show entries

[Pierre Smits (JIRA)]

Pierre Smits created OFBIZ-6949:
---

 Summary: Week  and day overview of calendar doesn't show entries
 Key: OFBIZ-6949
 URL: https://issues.apache.org/jira/browse/OFBIZ-6949
 Project: OFBiz
  Issue Type: Bug
  Components: workeffort
Affects Versions: Trunk
Reporter: Pierre Smits
 Attachments: Screen Shot 2016-03-21 at 20.00.17.png, Screen Shot 
2016-03-21 at 20.00.40.png, Screen Shot 2016-03-21 at 20.00.59.png

In WorkEffort, the calendar overview the month overview shows all entries. This 
not only applies to users with the WORKEFFORTMGR_ADMIN permission, but also to 
users with the WORKEFFORTMGR_VIEW permission.

However, when switching to the week view or or day view, the user with 
permission WORKEFFORTMGR_VIEW permission doesn't see the entries for that week 
or day view. While the user with permission WORKEFFORTMGR_ADMIN does.



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

[jira] [Reopened] (OFBIZ-6942) Comment out RMI related code because of the Java deserialization issue

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux reopened OFBIZ-6942:


This can be simpler as Jacopo explained

> Comment out RMI related code because of the Java deserialization issue
> --
>
> Key: OFBIZ-6942
> URL: https://issues.apache.org/jira/browse/OFBIZ-6942
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, 13.07.03, Upcoming Branch
>
>
> Because of the danger of Java deserialization when using RMI, we (PMC) have 
> decided to comment out RMI related code. I decided to comment out as less as 
> possible because once the RMI loaders, the RMI dispatcher and the related 
> test services are off there is no RMI related danger left (test services are 
> not a danger but would fail during tests run).  It's then easier for users 
> who need RMI in their projects to have only to uncomment those and not digg 
> everywhere. Because the naming (JNDI) server relies on the rmi loader it will 
> also be commented out.
> You can get more information in wiki page linked below in the "Issue Links" 
> section.



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

Re: svn commit: r1735569 - in /ofbiz/trunk/framework: base/config/ofbiz-containers.xml base/ofbiz-component.xml common/servicedef/services_test.xml service/ofbiz-component.xml start/src/org/ofbiz/base

[Jacques Le Roux]

Ah, indeed I did not clean before. After cleaning, using a clean working copy at "Révision : 1735435" (svn info), I get the same than you, can not run 
testRmi service and is-deserialized.txt contains not RMI reference


So it's pretty neat. I will revert my changes and use this change with both.properties and the rmi test services commented out. All that with the same 
comment, in only 3 places now.


Thanks!

Jacques


Le 21/03/2016 15:53, Jacopo Cappellato a écrit :

Ok,

I have applied my patch, and the output I get is:

  [java] 2016-03-21 15:50:18,632 |main |ContainerLoader
   |I| [Startup] Loading containers from
./framework/base/config/ofbiz-containers.xml for loaders [main]

However, in order to use the modified start.properties file you have to run:

./ant clean build

before start-secure

Could you please double check if you can get the same results?

Thanks,

Jacopo

On Mon, Mar 21, 2016 at 3:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


With start-secure target (same than start but with notsoserial protection
activated)

Ah, sorry wrote ant-secure target below :)

Jacques


Le 21/03/2016 15:18, Jacopo Cappellato a écrit :


Hi Jacques,

how did you get that log? (how did you start OFBiz)

Thanks,

Jacopo

On Sat, Mar 19, 2016 at 11:47 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Jacopo,

No it's not enough. Without the RmiDispatcher deactivated you can still
run RMI services like testRMI.
You get in log:

[java] 2016-03-18 18:39:22,787 |main |ContainerLoader   |I|
[Startup] Loading containers from
c:/projectsASF/ofbiz/framework/base/config/ofbiz-containers.xml for
loaders
[main, rmi]
[java] 2016-03-18 18:39:24,754 |main |ContainerLoader   |I|
Loading component's container: rmi-dispatcher
[java] 2016-03-18 18:39:24,755 |main |ContainerLoader   |I|
Loaded component's container: rmi-dispatcher
[java] 2016-03-18 18:39:27,966 |main |ContainerLoader   |I|
Starting container rmi-dispatcher
[java] 2016-03-18 18:39:29,346 |main |ServiceDispatcher |I|
Registering dispatcher: RMIDispatcher
[java] 2016-03-18 18:39:29,346 |main |ServiceContainer  |I|
Created new dispatcher: RMIDispatcher
[java] 2016-03-18 18:39:29,745 |main |ContainerLoader   |I|
Started container rmi-dispatcher

And if you use ant-secure target you see this in is-deserialized.txt

org.ofbiz.service.rmi.RemoteDispatcherImpl_Stub
java.rmi.server.RemoteStub
java.rmi.server.RemoteObject
org.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory
[Ljava.rmi.server.ObjID;
java.rmi.server.ObjID
java.rmi.server.UID
java.rmi.dgc.Lease
java.rmi.dgc.VMID

Those are not issues but shows that RMI is still active.

Actually I missed your change in start.properties but did the same in
both.properties.

Initially I wondered if the only thing needed was not to comment out the
RmiDispatcher in service/ofbiz-component.xml
Because once you have done that no RMI services can be used.
I finally decided to do more because the Distributed Clear Cache relies
on
JNDI, JMS and RMI. So I also deactivated the JNDI server and then got
further with all changes below.

Thinking about it now, since the the Rmi Service Dispatcher and the JNDI
server are at the root of all, it's maybe the only things which need to
be
deactivated (trying to minimise the changes) with of course the RMI test
services which would fail else.

What do you think?

Jacques


Le 18/03/2016 17:28, Jacopo Cappellato a écrit :

Hi Jacques,

thanks for working at this.
However I think that there is a simpler/better way to disable the
component
by default; by using the following patch:

Index: framework/start/src/org/ofbiz/base/start/start.properties
===
--- framework/start/src/org/ofbiz/base/start/start.properties (revision
1735404)
+++ framework/start/src/org/ofbiz/base/start/start.properties (working
copy)
@@ -40,7 +40,7 @@

# --- StartupLoader implementations to load (in order)
ofbiz.start.loader1=org.ofbiz.base.container.ContainerLoader
-ofbiz.start.loader1.loaders=main,rmi
+ofbiz.start.loader1.loaders=main

# -- Enable the shutdown hook
#ofbiz.enable.hook=true

I didn't test it but it should work!

Jacopo

On Fri, Mar 18, 2016 at 11:38 AM,  wrote:

Author: jleroux


Date: Fri Mar 18 10:38:04 2016
New Revision: 1735569

URL: http://svn.apache.org/viewvc?rev=1735569=rev
Log:
Fixes "Comment out RMI related code because of the Java deserialization
issue" - https://issues.apache.org/jira/browse/OFBIZ-6942

I decided to comment out as less as possible because once the RMI
loaders,
the RMI dispatcher and the related test services are off there is no
RMI
related danger left (test services are not a danger but would fail
during
tests run). It's then easier for users who need RMI in their projects
to
have only to uncomment those and not digg everywhere. Because 

[jira] [Updated] (OFBIZ-6845) On the balance sheet, it display incorrect value on the total of long-term asset.

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6845:
---
Fix Version/s: (was: Release Branch 12.04)
   15.12.01

> On the balance sheet, it display incorrect value on the total of long-term 
> asset.
> -
>
> Key: OFBIZ-6845
> URL: https://issues.apache.org/jira/browse/OFBIZ-6845
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Supatthra Nawicha
> Fix For: 14.12.01, Upcoming Branch, 15.12.01
>
> Attachments: addConditionForLongTermAsset.patch
>
>
> Now, it display the totals of all transactions of any assets. I have checked 
> on the code and I have found the missing condition checked in there. 
> {code:title=BalanceSheet.groovy|borderStyle=solid}
> List longtermAssetAndExprs = mainAndExprs as LinkedList;
> longtermAssetAndExprs.add(EntityCondition.makeCondition("glAccountClassId", 
> EntityOperator.IN, longtermAssetAccountClassIds));
> transactionTotals = select("glAccountId", "accountName", "accountCode", 
> "debitCreditFlag", 
> "amount").from("AcctgTransEntrySums").orderBy("glAccountId").queryList();
> {code}
> Actually, it should be:
> {code:java}
> List longtermAssetAndExprs = mainAndExprs as LinkedList;
> longtermAssetAndExprs.add(EntityCondition.makeCondition("glAccountClassId", 
> EntityOperator.IN, longtermAssetAccountClassIds));
> transactionTotals = select("glAccountId", "accountName", "accountCode", 
> "debitCreditFlag", 
> "amount").from("AcctgTransEntrySums").where(longtermAssetAndExprs).orderBy("glAccountId").queryList();
> {code}



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

Re: 15.12.01 unreleased version in Jira

[Jacques Le Roux]

Thanks for your explanation Jacopo, inline...

Le 21/03/2016 15:10, Jacopo Cappellato a écrit :

Jacques, thanks for raising this point that I think is worth of some
clarifications and enhancements to get the best out of the Jira reports.

When we backport a patch to the 15.12 branch, the patch will be published
in the first release of that branch: and this is why we need the 15.12.01
version and we should set the "fix version" to 15.12.01 rather than 15.12


Yes, I thought about it afterwards and I could see the reason.
So far I tried to remove all not released versions (like 15.12) out of the "fixed 
versions" field.
I used "Upcoming branch" for the not yet released branches.
And of course pending next release versions (like 13.07.02) when appropriate 
(ie when backporting in a supported and already released branch)

But if we have 2 unreleased branches (like at the moment 14 and 15) we indeed 
need to differentiate them.


"Upcoming branch" should be used to mark all the issues that are
implemented in the trunk and not backported in the release branches;


OK, I thought we were also using that for backports in not yet released 
branches.


when, at a later time, we create a new release branch from the trunk, this
release branch will of course contain all these enhancements/fixes; at that
point we should rename the "Upcoming branch" version into the name of the
first (future) release of the new branch and we should create a brand new
empty version with the name "Upcoming branch"


You mean rename in the admin side, right? So Jira will automatically relate all 
the issues with the new name.


Frankly speaking, I don't remember if I have done this when I have created
the 15.12 branch, but I think it should be good to move some of the tickets
accordingly, specifically:
* change all the issues with the "fix version" set to "release 15.12" to
"15.12.01"


I expect no issues with the "fix version" set to "release 15.12"
Because I monitored that and allowed only "Upcoming branch" or pending next 
release versions (like 13.07.02) in this field
(I just checked, indeed none)


* move the issues with the "fix version" set to "upcoming branch", that
have been backported to the 15.12 branch, to the "15.12.01" version


I can "easily" do that for the issues where I removed  "15.12.01" from the "Fix 
Version" field
For the others backported since the branch has been created it will be harder. 
Anyway we will do our best...

I also realise we did not use the (Community Day 1 - 2016 ends 28/Mar/16) 
enough in the recent effort.


I hope it makes any sense


Yes thanks!

Jacques



Jacopo

On Sun, Mar 20, 2016 at 8:09 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I ask this because not understanding the purpose I removed some in few
"Fix Version/s:" fields, thinking it was a duplicate of "Upcoming Branch"

Jacques


Le 20/03/2016 14:46, Jacques Le Roux a écrit :


I thought we were only using Upcoming Branch for that. So now the
Upcoming Branch is one which is not yet created or is 15.12.01 unreleased
version a duplicate?

Jacques

Le 20/03/2016 12:29, Jacopo Cappellato a écrit :


Hi Jacques,

I have added it because it is required as a "Fix for" version for patches
that are backported to the 15.12 release.

Jacopo

On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

Who added the 15.12.01 unreleased version in Jira and why?

Thanks

Jacques

[jira] [Updated] (OFBIZ-6568) Update Groovy to 2.4.5 version

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-6568:
---
Fix Version/s: (was: Release Branch 12.04)
   15.12.01

> Update Groovy to 2.4.5 version
> --
>
> Key: OFBIZ-6568
> URL: https://issues.apache.org/jira/browse/OFBIZ-6568
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Jacques Le Roux
>Assignee: Jacopo Cappellato
> Fix For: 14.12.01, 12.04.06, 13.07.03, Upcoming Branch, 15.12.01
>
>
> Since it's a security fix we should also update all  supported releases 
> branches. http://groovy-lang.org/security.html



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

[jira] [Created] (OFBIZ-6948) Days.groovy generates an error

[Pierre Smits (JIRA)]

Pierre Smits created OFBIZ-6948:
---

 Summary: Days.groovy generates an error
 Key: OFBIZ-6948
 URL: https://issues.apache.org/jira/browse/OFBIZ-6948
 Project: OFBiz
  Issue Type: Bug
  Components: workeffort
Affects Versions: Trunk
Reporter: Pierre Smits


When accessing a calendar day in workeffort the Days.groovy generates following 
error:
{code}

 [java] org.ofbiz.base.conversion.ConversionException: 
java.text.ParseException: Unparseable date: "145937520 00:00:00.000"
 [java] at 
org.ofbiz.base.conversion.DateTimeConverters$StringToTimestamp.convert(DateTimeConverters.java:671)
 ~[ofbiz-base.jar:?]
 [java] at 
org.ofbiz.base.conversion.DateTimeConverters$StringToTimestamp.convert(DateTimeConverters.java:618)
 ~[ofbiz-base.jar:?]
 [java] at 
org.ofbiz.base.util.ObjectType.simpleTypeConvert(ObjectType.java:543) 
[ofbiz-base.jar:?]
 [java] at 
org.ofbiz.service.ModelService.makeValid(ModelService.java:910) 
[ofbiz-service.jar:?]
 [java] at 
org.ofbiz.service.ModelService.makeValid(ModelService.java:838) 
[ofbiz-service.jar:?]
 [java] at 
org.ofbiz.service.ModelService.makeValid(ModelService.java:826) 
[ofbiz-service.jar:?]
 [java] at 
org.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:192) 
[ofbiz-service.jar:?]
 [java] at 
org.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:162) 
[ofbiz-service.jar:?]
 [java] at 
org.ofbiz.service.DispatchContext$makeValidContext.call(Unknown Source) 
[ofbiz-service.jar:?]
 [java] at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
 [groovy-all-2.4.5.jar:2.4.5]
 [java] at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
 [groovy-all-2.4.5.jar:2.4.5]
 [java] at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:141)
 [groovy-all-2.4.5.jar:2.4.5]
 [java] at Days.run(Days.groovy:38) [script:?]

{code}



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

Re: svn commit: r1735569 - in /ofbiz/trunk/framework: base/config/ofbiz-containers.xml base/ofbiz-component.xml common/servicedef/services_test.xml service/ofbiz-component.xml start/src/org/ofbiz/base

[Jacopo Cappellato]

Ok,

I have applied my patch, and the output I get is:

 [java] 2016-03-21 15:50:18,632 |main |ContainerLoader
  |I| [Startup] Loading containers from
./framework/base/config/ofbiz-containers.xml for loaders [main]

However, in order to use the modified start.properties file you have to run:

./ant clean build

before start-secure

Could you please double check if you can get the same results?

Thanks,

Jacopo

On Mon, Mar 21, 2016 at 3:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> With start-secure target (same than start but with notsoserial protection
> activated)
>
> Ah, sorry wrote ant-secure target below :)
>
> Jacques
>
>
> Le 21/03/2016 15:18, Jacopo Cappellato a écrit :
>
>> Hi Jacques,
>>
>> how did you get that log? (how did you start OFBiz)
>>
>> Thanks,
>>
>> Jacopo
>>
>> On Sat, Mar 19, 2016 at 11:47 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> Hi Jacopo,
>>>
>>> No it's not enough. Without the RmiDispatcher deactivated you can still
>>> run RMI services like testRMI.
>>> You get in log:
>>>
>>> [java] 2016-03-18 18:39:22,787 |main |ContainerLoader   |I|
>>> [Startup] Loading containers from
>>> c:/projectsASF/ofbiz/framework/base/config/ofbiz-containers.xml for
>>> loaders
>>> [main, rmi]
>>> [java] 2016-03-18 18:39:24,754 |main |ContainerLoader   |I|
>>> Loading component's container: rmi-dispatcher
>>> [java] 2016-03-18 18:39:24,755 |main |ContainerLoader   |I|
>>> Loaded component's container: rmi-dispatcher
>>> [java] 2016-03-18 18:39:27,966 |main |ContainerLoader   |I|
>>> Starting container rmi-dispatcher
>>> [java] 2016-03-18 18:39:29,346 |main |ServiceDispatcher |I|
>>> Registering dispatcher: RMIDispatcher
>>> [java] 2016-03-18 18:39:29,346 |main |ServiceContainer  |I|
>>> Created new dispatcher: RMIDispatcher
>>> [java] 2016-03-18 18:39:29,745 |main |ContainerLoader   |I|
>>> Started container rmi-dispatcher
>>>
>>> And if you use ant-secure target you see this in is-deserialized.txt
>>>
>>> org.ofbiz.service.rmi.RemoteDispatcherImpl_Stub
>>> java.rmi.server.RemoteStub
>>> java.rmi.server.RemoteObject
>>> org.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory
>>> [Ljava.rmi.server.ObjID;
>>> java.rmi.server.ObjID
>>> java.rmi.server.UID
>>> java.rmi.dgc.Lease
>>> java.rmi.dgc.VMID
>>>
>>> Those are not issues but shows that RMI is still active.
>>>
>>> Actually I missed your change in start.properties but did the same in
>>> both.properties.
>>>
>>> Initially I wondered if the only thing needed was not to comment out the
>>> RmiDispatcher in service/ofbiz-component.xml
>>> Because once you have done that no RMI services can be used.
>>> I finally decided to do more because the Distributed Clear Cache relies
>>> on
>>> JNDI, JMS and RMI. So I also deactivated the JNDI server and then got
>>> further with all changes below.
>>>
>>> Thinking about it now, since the the Rmi Service Dispatcher and the JNDI
>>> server are at the root of all, it's maybe the only things which need to
>>> be
>>> deactivated (trying to minimise the changes) with of course the RMI test
>>> services which would fail else.
>>>
>>> What do you think?
>>>
>>> Jacques
>>>
>>>
>>> Le 18/03/2016 17:28, Jacopo Cappellato a écrit :
>>>
>>> Hi Jacques,

 thanks for working at this.
 However I think that there is a simpler/better way to disable the
 component
 by default; by using the following patch:

 Index: framework/start/src/org/ofbiz/base/start/start.properties
 ===
 --- framework/start/src/org/ofbiz/base/start/start.properties (revision
 1735404)
 +++ framework/start/src/org/ofbiz/base/start/start.properties (working
 copy)
 @@ -40,7 +40,7 @@

# --- StartupLoader implementations to load (in order)
ofbiz.start.loader1=org.ofbiz.base.container.ContainerLoader
 -ofbiz.start.loader1.loaders=main,rmi
 +ofbiz.start.loader1.loaders=main

# -- Enable the shutdown hook
#ofbiz.enable.hook=true

 I didn't test it but it should work!

 Jacopo

 On Fri, Mar 18, 2016 at 11:38 AM,  wrote:

 Author: jleroux

> Date: Fri Mar 18 10:38:04 2016
> New Revision: 1735569
>
> URL: http://svn.apache.org/viewvc?rev=1735569=rev
> Log:
> Fixes "Comment out RMI related code because of the Java deserialization
> issue" - https://issues.apache.org/jira/browse/OFBIZ-6942
>
> I decided to comment out as less as possible because once the RMI
> loaders,
> the RMI dispatcher and the related test services are off there is no
> RMI
> related danger left (test services are not a danger but would fail
> during
> tests run). It's then easier for users who need RMI in their projects
> to
> have only to uncomment 

Re: svn commit: r1735569 - in /ofbiz/trunk/framework: base/config/ofbiz-containers.xml base/ofbiz-component.xml common/servicedef/services_test.xml service/ofbiz-component.xml start/src/org/ofbiz/base

[Jacques Le Roux]

With start-secure target (same than start but with notsoserial protection 
activated)

Ah, sorry wrote ant-secure target below :)

Jacques

Le 21/03/2016 15:18, Jacopo Cappellato a écrit :

Hi Jacques,

how did you get that log? (how did you start OFBiz)

Thanks,

Jacopo

On Sat, Mar 19, 2016 at 11:47 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Jacopo,

No it's not enough. Without the RmiDispatcher deactivated you can still
run RMI services like testRMI.
You get in log:

[java] 2016-03-18 18:39:22,787 |main |ContainerLoader   |I|
[Startup] Loading containers from
c:/projectsASF/ofbiz/framework/base/config/ofbiz-containers.xml for loaders
[main, rmi]
[java] 2016-03-18 18:39:24,754 |main |ContainerLoader   |I|
Loading component's container: rmi-dispatcher
[java] 2016-03-18 18:39:24,755 |main |ContainerLoader   |I|
Loaded component's container: rmi-dispatcher
[java] 2016-03-18 18:39:27,966 |main |ContainerLoader   |I|
Starting container rmi-dispatcher
[java] 2016-03-18 18:39:29,346 |main |ServiceDispatcher |I|
Registering dispatcher: RMIDispatcher
[java] 2016-03-18 18:39:29,346 |main |ServiceContainer  |I|
Created new dispatcher: RMIDispatcher
[java] 2016-03-18 18:39:29,745 |main |ContainerLoader   |I|
Started container rmi-dispatcher

And if you use ant-secure target you see this in is-deserialized.txt

org.ofbiz.service.rmi.RemoteDispatcherImpl_Stub
java.rmi.server.RemoteStub
java.rmi.server.RemoteObject
org.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory
[Ljava.rmi.server.ObjID;
java.rmi.server.ObjID
java.rmi.server.UID
java.rmi.dgc.Lease
java.rmi.dgc.VMID

Those are not issues but shows that RMI is still active.

Actually I missed your change in start.properties but did the same in
both.properties.

Initially I wondered if the only thing needed was not to comment out the
RmiDispatcher in service/ofbiz-component.xml
Because once you have done that no RMI services can be used.
I finally decided to do more because the Distributed Clear Cache relies on
JNDI, JMS and RMI. So I also deactivated the JNDI server and then got
further with all changes below.

Thinking about it now, since the the Rmi Service Dispatcher and the JNDI
server are at the root of all, it's maybe the only things which need to be
deactivated (trying to minimise the changes) with of course the RMI test
services which would fail else.

What do you think?

Jacques


Le 18/03/2016 17:28, Jacopo Cappellato a écrit :


Hi Jacques,

thanks for working at this.
However I think that there is a simpler/better way to disable the
component
by default; by using the following patch:

Index: framework/start/src/org/ofbiz/base/start/start.properties
===
--- framework/start/src/org/ofbiz/base/start/start.properties (revision
1735404)
+++ framework/start/src/org/ofbiz/base/start/start.properties (working
copy)
@@ -40,7 +40,7 @@

   # --- StartupLoader implementations to load (in order)
   ofbiz.start.loader1=org.ofbiz.base.container.ContainerLoader
-ofbiz.start.loader1.loaders=main,rmi
+ofbiz.start.loader1.loaders=main

   # -- Enable the shutdown hook
   #ofbiz.enable.hook=true

I didn't test it but it should work!

Jacopo

On Fri, Mar 18, 2016 at 11:38 AM,  wrote:

Author: jleroux

Date: Fri Mar 18 10:38:04 2016
New Revision: 1735569

URL: http://svn.apache.org/viewvc?rev=1735569=rev
Log:
Fixes "Comment out RMI related code because of the Java deserialization
issue" - https://issues.apache.org/jira/browse/OFBIZ-6942

I decided to comment out as less as possible because once the RMI
loaders,
the RMI dispatcher and the related test services are off there is no RMI
related danger left (test services are not a danger but would fail during
tests run). It's then easier for users who need RMI in their projects to
have only to uncomment those and not digg everywhere. Because the naming
(JNDI) server relies on the rmi loader it will also be commented out.

Modified:
  ofbiz/trunk/framework/base/config/ofbiz-containers.xml
  ofbiz/trunk/framework/base/ofbiz-component.xml
  ofbiz/trunk/framework/common/servicedef/services_test.xml
  ofbiz/trunk/framework/service/ofbiz-component.xml
  ofbiz/trunk/framework/start/src/org/ofbiz/base/start/both.properties

Modified: ofbiz/trunk/framework/base/config/ofbiz-containers.xml
URL:

http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/config/ofbiz-containers.xml?rev=1735569=1735568=1735569=diff


==
--- ofbiz/trunk/framework/base/config/ofbiz-containers.xml (original)
+++ ofbiz/trunk/framework/base/config/ofbiz-containers.xml Fri Mar 18
10:38:04 2016
@@ -21,8 +21,11 @@ under the License.
   http://www.w3.org/2001/XMLSchema-instance
"
   xsi:noNamespaceSchemaLocation="
http://ofbiz.apache.org/dtds/ofbiz-containers.xsd;>

+
   

Re: svn commit: r1735569 - in /ofbiz/trunk/framework: base/config/ofbiz-containers.xml base/ofbiz-component.xml common/servicedef/services_test.xml service/ofbiz-component.xml start/src/org/ofbiz/base

[Jacopo Cappellato]

Hi Jacques,

how did you get that log? (how did you start OFBiz)

Thanks,

Jacopo

On Sat, Mar 19, 2016 at 11:47 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Jacopo,
>
> No it's not enough. Without the RmiDispatcher deactivated you can still
> run RMI services like testRMI.
> You get in log:
>
> [java] 2016-03-18 18:39:22,787 |main |ContainerLoader   |I|
> [Startup] Loading containers from
> c:/projectsASF/ofbiz/framework/base/config/ofbiz-containers.xml for loaders
> [main, rmi]
> [java] 2016-03-18 18:39:24,754 |main |ContainerLoader   |I|
> Loading component's container: rmi-dispatcher
> [java] 2016-03-18 18:39:24,755 |main |ContainerLoader   |I|
> Loaded component's container: rmi-dispatcher
> [java] 2016-03-18 18:39:27,966 |main |ContainerLoader   |I|
> Starting container rmi-dispatcher
> [java] 2016-03-18 18:39:29,346 |main |ServiceDispatcher |I|
> Registering dispatcher: RMIDispatcher
> [java] 2016-03-18 18:39:29,346 |main |ServiceContainer  |I|
> Created new dispatcher: RMIDispatcher
> [java] 2016-03-18 18:39:29,745 |main |ContainerLoader   |I|
> Started container rmi-dispatcher
>
> And if you use ant-secure target you see this in is-deserialized.txt
>
> org.ofbiz.service.rmi.RemoteDispatcherImpl_Stub
> java.rmi.server.RemoteStub
> java.rmi.server.RemoteObject
> org.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory
> [Ljava.rmi.server.ObjID;
> java.rmi.server.ObjID
> java.rmi.server.UID
> java.rmi.dgc.Lease
> java.rmi.dgc.VMID
>
> Those are not issues but shows that RMI is still active.
>
> Actually I missed your change in start.properties but did the same in
> both.properties.
>
> Initially I wondered if the only thing needed was not to comment out the
> RmiDispatcher in service/ofbiz-component.xml
> Because once you have done that no RMI services can be used.
> I finally decided to do more because the Distributed Clear Cache relies on
> JNDI, JMS and RMI. So I also deactivated the JNDI server and then got
> further with all changes below.
>
> Thinking about it now, since the the Rmi Service Dispatcher and the JNDI
> server are at the root of all, it's maybe the only things which need to be
> deactivated (trying to minimise the changes) with of course the RMI test
> services which would fail else.
>
> What do you think?
>
> Jacques
>
>
> Le 18/03/2016 17:28, Jacopo Cappellato a écrit :
>
>> Hi Jacques,
>>
>> thanks for working at this.
>> However I think that there is a simpler/better way to disable the
>> component
>> by default; by using the following patch:
>>
>> Index: framework/start/src/org/ofbiz/base/start/start.properties
>> ===
>> --- framework/start/src/org/ofbiz/base/start/start.properties (revision
>> 1735404)
>> +++ framework/start/src/org/ofbiz/base/start/start.properties (working
>> copy)
>> @@ -40,7 +40,7 @@
>>
>>   # --- StartupLoader implementations to load (in order)
>>   ofbiz.start.loader1=org.ofbiz.base.container.ContainerLoader
>> -ofbiz.start.loader1.loaders=main,rmi
>> +ofbiz.start.loader1.loaders=main
>>
>>   # -- Enable the shutdown hook
>>   #ofbiz.enable.hook=true
>>
>> I didn't test it but it should work!
>>
>> Jacopo
>>
>> On Fri, Mar 18, 2016 at 11:38 AM,  wrote:
>>
>> Author: jleroux
>>> Date: Fri Mar 18 10:38:04 2016
>>> New Revision: 1735569
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1735569=rev
>>> Log:
>>> Fixes "Comment out RMI related code because of the Java deserialization
>>> issue" - https://issues.apache.org/jira/browse/OFBIZ-6942
>>>
>>> I decided to comment out as less as possible because once the RMI
>>> loaders,
>>> the RMI dispatcher and the related test services are off there is no RMI
>>> related danger left (test services are not a danger but would fail during
>>> tests run). It's then easier for users who need RMI in their projects to
>>> have only to uncomment those and not digg everywhere. Because the naming
>>> (JNDI) server relies on the rmi loader it will also be commented out.
>>>
>>> Modified:
>>>  ofbiz/trunk/framework/base/config/ofbiz-containers.xml
>>>  ofbiz/trunk/framework/base/ofbiz-component.xml
>>>  ofbiz/trunk/framework/common/servicedef/services_test.xml
>>>  ofbiz/trunk/framework/service/ofbiz-component.xml
>>>  ofbiz/trunk/framework/start/src/org/ofbiz/base/start/both.properties
>>>
>>> Modified: ofbiz/trunk/framework/base/config/ofbiz-containers.xml
>>> URL:
>>>
>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/config/ofbiz-containers.xml?rev=1735569=1735568=1735569=diff
>>>
>>>
>>> ==
>>> --- ofbiz/trunk/framework/base/config/ofbiz-containers.xml (original)
>>> +++ ofbiz/trunk/framework/base/config/ofbiz-containers.xml Fri Mar 18
>>> 10:38:04 2016
>>> @@ -21,8 +21,11 @@ under the License.
>>>   

Re: 15.12.01 unreleased version in Jira

[Jacopo Cappellato]

Jacques, thanks for raising this point that I think is worth of some
clarifications and enhancements to get the best out of the Jira reports.

When we backport a patch to the 15.12 branch, the patch will be published
in the first release of that branch: and this is why we need the 15.12.01
version and we should set the "fix version" to 15.12.01 rather than 15.12

"Upcoming branch" should be used to mark all the issues that are
implemented in the trunk and not backported in the release branches; when,
at a later time, we create a new release branch from the trunk, this
release branch will of course contain all these enhancements/fixes; at that
point we should rename the "Upcoming branch" version into the name of the
first (future) release of the new branch and we should create a brand new
empty version with the name "Upcoming branch"

Frankly speaking, I don't remember if I have done this when I have created
the 15.12 branch, but I think it should be good to move some of the tickets
accordingly, specifically:
* change all the issues with the "fix version" set to "release 15.12" to
"15.12.01"
* move the issues with the "fix version" set to "upcoming branch", that
have been backported to the 15.12 branch, to the "15.12.01" version

I hope it makes any sense

Jacopo

On Sun, Mar 20, 2016 at 8:09 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I ask this because not understanding the purpose I removed some in few
> "Fix Version/s:" fields, thinking it was a duplicate of "Upcoming Branch"
>
> Jacques
>
>
> Le 20/03/2016 14:46, Jacques Le Roux a écrit :
>
>> I thought we were only using Upcoming Branch for that. So now the
>> Upcoming Branch is one which is not yet created or is 15.12.01 unreleased
>> version a duplicate?
>>
>> Jacques
>>
>> Le 20/03/2016 12:29, Jacopo Cappellato a écrit :
>>
>>> Hi Jacques,
>>>
>>> I have added it because it is required as a "Fix for" version for patches
>>> that are backported to the 15.12 release.
>>>
>>> Jacopo
>>>
>>> On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> Hi,

 Who added the 15.12.01 unreleased version in Jira and why?

 Thanks

 Jacques


>>

Re: Spreadsheet file handler creation

[Ron Wheeler]

It can also output HTML files fully annotated for CSS styling.

It also can create reports using JasperReport.

It can read CSV (with and without headers) and Excel files.

It can be extended by plug-ins to read anything that you can parse into 
row and columns

Webservice and SQL connections are possible sources for data.


Ron




On 21/03/2016 9:16 AM, Leila Mekika wrote:

Hello Ron,

i didn't know about ADTransform and will look at it. Actually, my goal 
is to make an export file and it seems to allow spreadsheet output.
But i already had the need to make a spreadsheet to xml conversion for 
import purpose, so i'll keep that in mind (and your post in 
adtransform website)

Thanks !

Leila

Le 19/03/2016 02:38, Ron Wheeler a écrit :

ADTransform will do most (perhaps all) of what you want.

It will read a spreadsheet (or a CSV file), let you manipulate the 
data, verify it and then produce a set of XML files.
I have done a partial script to take multiple spreadsheets and create 
OFBiz XML entity files.


The OFBiz XML structure is fairly complex and to load a simple 
spreadsheet  containing a list of customers with their names, 
addresses, email, phone numbers starts with a pretty simple 
spreadsheet but ends up with many, many XML files. Spreadsheets with 
Customers, Customer Service employees and SIC codes generate 19 XML 
files!



Ron


On 18/03/2016 6:05 AM, Leila wrote:

Hello everyone,

We had to do a spreadsheet file handler for a customer project and 
decided to use current csv renderer to generate a datafile, then 
convert it to xls with Workbook library.
It turns out to be very long when extracted file reaches a big load 
of data...


In order to resolve this, i am currently trying to make a new 
handler that generate a html table file which can be imported as 
spreadsheet in most office software suite (i've made a JIRA 
). Cells are 
formatted via css (found this 
).
The generated file is an html file with application/xls response 
content-type, since i didnt' find any "html to ods" or "html to xls" 
converter. I think it's because it can be done from the software 
suite interface, but i was wondering: does anyone know of a library 
that can transform html to spreadsheet file ?


Does anyone has another suggestion than the html generation to 
achieve a fast spreadsheet file rendering ?

Thanks for any idea or advice

Leila Mekika










--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Spreadsheet file handler creation

[Leila Mekika]

Hello Ron,

i didn't know about ADTransform and will look at it. Actually, my goal 
is to make an export file and it seems to allow spreadsheet output.
But i already had the need to make a spreadsheet to xml conversion for 
import purpose, so i'll keep that in mind (and your post in adtransform 
website)

Thanks !

Leila

Le 19/03/2016 02:38, Ron Wheeler a écrit :

ADTransform will do most (perhaps all) of what you want.

It will read a spreadsheet (or a CSV file), let you manipulate the 
data, verify it and then produce a set of XML files.
I have done a partial script to take multiple spreadsheets and create 
OFBiz XML entity files.


The OFBiz XML structure is fairly complex and to load a simple 
spreadsheet  containing a list of customers with their names, 
addresses, email, phone numbers starts with a pretty simple 
spreadsheet but ends up with many, many XML files. Spreadsheets with 
Customers, Customer Service employees and SIC codes generate 19 XML 
files!



Ron


On 18/03/2016 6:05 AM, Leila wrote:

Hello everyone,

We had to do a spreadsheet file handler for a customer project and 
decided to use current csv renderer to generate a datafile, then 
convert it to xls with Workbook library.
It turns out to be very long when extracted file reaches a big load 
of data...


In order to resolve this, i am currently trying to make a new handler 
that generate a html table file which can be imported as spreadsheet 
in most office software suite (i've made a JIRA 
). Cells are 
formatted via css (found this 
).
The generated file is an html file with application/xls response 
content-type, since i didnt' find any "html to ods" or "html to xls" 
converter. I think it's because it can be done from the software 
suite interface, but i was wondering: does anyone know of a library 
that can transform html to spreadsheet file ?


Does anyone has another suggestion than the html generation to 
achieve a fast spreadsheet file rendering ?

Thanks for any idea or advice

Leila Mekika

Re: Spreadsheet file handler creation

[Leila Mekika]

Thanks Shi for your answer,

Sorry i didn't express myself well: in fact i was refering to POI when i 
said that we use to convert the csv to xls with workbook library.
But we've got memory issues with some files so i try to find an other 
way :-)


Leila

Le 19/03/2016 01:31, Shi Jinghai a écrit :

I think POI is the right way, you can handle an excel template file directly 
without any conversion.

It's in my plan (maybe in May) to contribute a PriCat component which can 
import/export excel file for EDI purpose.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Leila [mailto:leila.mek...@nereide.fr]
发送时间: 2016年3月18日 18:05
收件人:dev@ofbiz.apache.org
主题: Spreadsheet file handler creation

Hello everyone,

We had to do a spreadsheet file handler for a customer project and
decided to use current csv renderer to generate a datafile, then convert
it to xls with Workbook library.
It turns out to be very long when extracted file reaches a big load of
data...

In order to resolve this, i am currently trying to make a new handler
that generate a html table file which can be imported as spreadsheet in
most office software suite (i've made a JIRA
). Cells are formatted
via css (found this
).
The generated file is an html file with application/xls response
content-type, since i didnt' find any "html to ods" or "html to xls"
converter. I think it's because it can be done from the software suite
interface, but i was wondering: does anyone know of a library that can
transform html to spreadsheet file ?

Does anyone has another suggestion than the html generation to achieve a
fast spreadsheet file rendering ?
Thanks for any idea or advice

Leila Mekika

[jira] [Updated] (OFBIZ-5703) When we delete uploaded project content then it is deletes but form is coming in update mode with content Id

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-5703:
---
Summary: When we delete uploaded  project content then it is deletes but 
form is coming in update mode with content Id(was: When We delete uploaded  
project contenat then it is delete but form is come in update mode with content 
Id  )

> When we delete uploaded  project content then it is deletes but form is 
> coming in update mode with content Id  
> ---
>
> Key: OFBIZ-5703
> URL: https://issues.apache.org/jira/browse/OFBIZ-5703
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/projectmgr
>Affects Versions: 11.04.04, Trunk, 12.04.04
>Reporter: Dhiraj Gupta
>Assignee: Divesh Dutta
>
> When We go to this link 
> http://demo-trunk-ofbiz.apache.org/projectmgr/control/main, project name list 
> is diaplay. We click  on project name  button link, this will lead to project 
> profile.We click on content sub menus this  will open the  upload form and 
> list of the uploaded content.When  we delete  the  uploaded contnent form 
> list 
>   then it will  delete but form is come in update mode with content Id below 
> list.
> Thanks
> Dhiraj  



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

Buildbot builds don't fire on R15.12 commits

[Jacques Le Roux]

FYI: https://issues.apache.org/jira/browse/INFRA-5

Jacques