date:20140831


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

Jacques Le Roux edited comment on OFBIZ-5113 at 8/31/14 7:27 AM:
-

Done, thanks for your work Nicolas :)


was (Author: jacques.le.roux):
Done, thanks for you work Nicolas :)

 Update wiki documentation on load data
 --

 Key: OFBIZ-5113
 URL: https://issues.apache.org/jira/browse/OFBIZ-5113
 Project: OFBiz
  Issue Type: Task
  Components: framework
Affects Versions: Trunk
Reporter: Nicolas Malin
Priority: Trivial
  Labels: documentation, entityengine

 After issue commit OFBIZ-4949, it's necessary to update the wiki 
 documentation :
 * 
 https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide#OFBizTutorial-ABeginnersDevelopmentGuide-PreparingDataForCustomApplication
 * https://cwiki.apache.org/confluence/display/OFBIZ/Handling+of+External+data



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer

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

Jacques Le Roux commented on OFBIZ-5704:

[~pfm.smits] I don't clearly understand why you reject the idea of having a
Role between the Lot and Party? It does not prevent to do what you want. I
can't see only one reason: have you already coded it like this in your software?

[~chrisg] I'm not quite sure to inderstand you. On one hand you say
bq. I'm sure there are companies who handle their lot ids like this (use vendor
lot id), but others want to have their own lot id AND record the vendor lot id.
Which goes the same way than Adrian, Nicolas and I suggest. On the other hand
you say
bq. I think the best way to implement this is to add an new field vendorLotId
(or maybe LotAttributes/LotFeatures).
It's not quite clear to me where this field would be be added? If it's to the
Lot then you go the same way than Pierre. Could you please clarify?

Extend lot entity to include party Id of manufacturer
-

Key: OFBIZ-5704
URL: https://issues.apache.org/jira/browse/OFBIZ-5704
Project: OFBiz
Issue Type: Improvement
Components: manufacturing, product, workeffort
Affects Versions: Release Branch 11.04, Release Branch 12.04, Release
Branch 13.07, Trunk
Reporter: Pierre Smits
Attachments: OFBiz-5704-Product-EntityModel-Lot.patch

Rationale
Lot or batch management affects two places, namely the outbound process (and
its functionalities) and inbound.
It is possible that multiple parties have the same ID for the batch or the
lot. Howver, in current feature set there is no discrimination between lots
from supplier A, supplier B, or even the primary (internal) company in OFBiz.
Therefore the entity 'Lot' should be extended with another key, namely that
of the partyId of the manufacturer (or supplier).

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-5737) Add/Revise Traditional Chinese (zh-TW) translations in framework


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

Jacques Le Roux commented on OFBIZ-5737:


@nhlotwn I have asked [~shi.jinghai] if he could review your changes (even 
cursorily to have an idea of the quality). Let's see if him or another agree 
with them. I remember a small conflict we had previously in the Chinese 
community when changing labels. If nobody answer I will though soon commits 
your adds waiting for a review, thanks for your work!

 Add/Revise Traditional Chinese (zh-TW) translations in framework
 

 Key: OFBIZ-5737
 URL: https://issues.apache.org/jira/browse/OFBIZ-5737
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Upcoming Branch
Reporter: Nick Ho
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch

 Attachments: framework-translation-zh-TW.patch, 
 framework-translation-zh-TW.patch, framework-translation-zh-TW.patch, 
 framework-translation-zh-TW.patch, patch.log, patch.log, patch.log


 more added/updated translations patch files for zh-TW locale



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (OFBIZ-5733) Update Derby to last 10.11.1.1 version (security fixes included)


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

Jacques Le Roux reassigned OFBIZ-5733:
--

Assignee: Jacques Le Roux

 Update Derby to last 10.11.1.1 version (security fixes included)
 

 Key: OFBIZ-5733
 URL: https://issues.apache.org/jira/browse/OFBIZ-5733
 Project: OFBiz
  Issue Type: Task
  Components: framework
Affects Versions: 11.04.06, 12.04.05, 13.07.01, Upcoming Branch
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
  Labels: Derby

 There are security issues fixed in this release though none seem important
 http://db.apache.org/derby/releases/release-10.11.1.1.cgi
 I have not verified yet if we need changes in OFBiz code (I would be 
 surprised) in order to update tho this Derby version
 Note: I like the way they show their release notes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Discussion: Service Engine Refactoring

Currently, the service engine classes are a bit muddled. 
GenericDispatcher (the default LocalDispatcher implementation) and 
DispatchContext have feature envy. Some functionality in DispatchContext 
belongs in ServiceDispatcher.


I would like to clean this up a bit and provide better separation of 
concerns. The service engine API will not change - the work will be done 
under the hood.


My hope is to get the code to a point where DispatchContext becomes less 
integral to its neighbors, and it becomes more of a single-use 
lightweight container. Again, this will not change the API at all.


However, it will open up the possibility to improve the API. For 
example, instead of this service implementation:


public static MapString, Object myService(DispatchContext dctx, 
MapString, Object context) {

  Locale locale = (Locale) context.get(locale);
...

we could have:

public static MapString, Object myService(DispatchContext dctx) {
  Locale locale = dctx.getParameter(locale);
...


What do you think?


--
Adrian Crum
Sandglass Software
www.sandglass-software.com

Re: Discussion: Service Engine Refactoring

2014-08-31 Thread Jacopo Cappellato

Thank you Adrian,

please see inline:

On Aug 31, 2014, at 10:50 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:

 Currently, the service engine classes are a bit muddled. GenericDispatcher 
 (the default LocalDispatcher implementation) and DispatchContext have feature 
 envy. Some functionality in DispatchContext belongs in ServiceDispatcher.
 
 I would like to clean this up a bit and provide better separation of 
 concerns. The service engine API will not change - the work will be done 
 under the hood.
 
 My hope is to get the code to a point where DispatchContext becomes less 
 integral to its neighbors, and it becomes more of a single-use lightweight 
 container. Again, this will not change the API at all.

I think it would help the other committers to provide feedback if you could (in 
just a few sentences) summarize the following:
a) what is the original concern of DispatchContext and of GenericDispatcher
b) where do you see that this concerns are not well implemented in the code
c) if you would like to modify #a, quickly describe the new purposes of the 
classes in your vision
d) what are the methods/fields that you would like to move from DispatchContext

Thanks

Jacopo

PS: in general I also see a lot of code that should be cleaned in 
DispatchContext; for example, the initialization of the static map in the 
constructor, the method getAllServiceNames() that should be static, bad 
thread-safe implementation, probably the modelServiceMapByModel should not even 
be there... 

 
 However, it will open up the possibility to improve the API. For example, 
 instead of this service implementation:
 
 public static MapString, Object myService(DispatchContext dctx, MapString, 
 Object context) {
  Locale locale = (Locale) context.get(locale);
 ...
 
 we could have:
 
 public static MapString, Object myService(DispatchContext dctx) {
  Locale locale = dctx.getParameter(locale);
 ...
 
 
 What do you think?
 
 
 -- 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com

Re: Discussion: Service Engine Refactoring

2014-08-31 Thread Jacopo Cappellato


On Aug 31, 2014, at 10:50 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:

 However, it will open up the possibility to improve the API. For example, 
 instead of this service implementation:
 
 public static MapString, Object myService(DispatchContext dctx, MapString, 
 Object context) {
  Locale locale = (Locale) context.get(locale);
 ...
 
 we could have:
 
 public static MapString, Object myService(DispatchContext dctx) {
  Locale locale = dctx.getParameter(locale);
 ...

DispatchContext and the Map with input parameters have a completely different 
purpose and I don't think this would be an improvement per se. We will have 
to revisit this conversation at some point to be sure we are in the same page.

Jacopo

Re: Discussion: Service Engine Refactoring

2014-08-31 Thread Jacopo Cappellato


On Aug 31, 2014, at 11:36 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 a) what is the original concern of DispatchContext and of GenericDispatcher

This comes from this old but still interesting document: 
http://ofbiz.apache.org/docs/services.html


*Service Dispatcher*

The Service Dispatcher handles dispatching services to the appropriate Service 
Engine where it is then invoked. There is exactly one ServiceDispatcher for 
each Entity Delegator. If there are multiple delegators in an application there 
will also be multiple dispatchers. The ServiceDispatcher is accessed via a 
LocalDispatcher. There can be many LocalDispatchers associated with a 
ServiceDispatcher. Each LocalDispatcher is uniquely named and contains its own 
list of service definitions. When creating an instance of a LocalDispatcher, a 
DispatchContext is also created and passed to the ServiceEngine.

A LocalDispatcher is associated with an application. Applications never talk 
directly to the ServiceDispatcher. The LocalDispatcher contains an API for 
invoking services, which are routed through the ServiceDispather. However, 
applications may be running in different threads than the actual 
ServiceDispatcher, so it is left to the LocalDispatcher to keep a 
DispatchContext which among other things keeps a reference to the applications 
classloader.

*Dispatch Context*

The DispatchContext is created by the LocalDispatcher upon instantiation. This 
is the runtime dispatcher context. It contains necessary information to process 
services for each dispatcher. This context contains the reference to each of 
the service definition files, the classloader which should be used for 
invocation, a reference to the delegator and its dispatcher along with a 'bag' 
of user defined attributes. This context is passed on to each service when 
invoked and is used by the dispatcher to determine the service's model.



Jacopo

Re: Discussion: Service Engine Refactoring

That last paragraph describes the cleanup I want to do. If a 
LocalDispatcher contains things specific to an application, then why are 
some of those things kept in GenericDispatcher and others are kept in 
DispatchContext? This is the feature-envy part - they are both trying to 
be the same thing.


It would simpler and cleaner if we keep application-specific bits in 
GenericDispatcher, and just have DispatchContext reference it.



Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 10:56 AM, Jacopo Cappellato wrote:


On Aug 31, 2014, at 11:36 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:


a) what is the original concern of DispatchContext and of GenericDispatcher


This comes from this old but still interesting document: 
http://ofbiz.apache.org/docs/services.html


*Service Dispatcher*

The Service Dispatcher handles dispatching services to the appropriate Service 
Engine where it is then invoked. There is exactly one ServiceDispatcher for 
each Entity Delegator. If there are multiple delegators in an application there 
will also be multiple dispatchers. The ServiceDispatcher is accessed via a 
LocalDispatcher. There can be many LocalDispatchers associated with a 
ServiceDispatcher. Each LocalDispatcher is uniquely named and contains its own 
list of service definitions. When creating an instance of a LocalDispatcher, a 
DispatchContext is also created and passed to the ServiceEngine.

A LocalDispatcher is associated with an application. Applications never talk 
directly to the ServiceDispatcher. The LocalDispatcher contains an API for 
invoking services, which are routed through the ServiceDispather. However, 
applications may be running in different threads than the actual 
ServiceDispatcher, so it is left to the LocalDispatcher to keep a 
DispatchContext which among other things keeps a reference to the applications 
classloader.

*Dispatch Context*

The DispatchContext is created by the LocalDispatcher upon instantiation. This 
is the runtime dispatcher context. It contains necessary information to process 
services for each dispatcher. This context contains the reference to each of 
the service definition files, the classloader which should be used for 
invocation, a reference to the delegator and its dispatcher along with a 'bag' 
of user defined attributes. This context is passed on to each service when 
invoked and is used by the dispatcher to determine the service's model.



Jacopo

Re: Discussion: Service Engine Refactoring


Inline...

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 10:36 AM, Jacopo Cappellato wrote:

Thank you Adrian,

please see inline:

On Aug 31, 2014, at 10:50 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:


Currently, the service engine classes are a bit muddled. GenericDispatcher (the 
default LocalDispatcher implementation) and DispatchContext have feature envy. 
Some functionality in DispatchContext belongs in ServiceDispatcher.

I would like to clean this up a bit and provide better separation of concerns. The 
service engine API will not change - the work will be done under the hood.

My hope is to get the code to a point where DispatchContext becomes less 
integral to its neighbors, and it becomes more of a single-use lightweight 
container. Again, this will not change the API at all.


I think it would help the other committers to provide feedback if you could (in 
just a few sentences) summarize the following:
a) what is the original concern of DispatchContext and of GenericDispatcher



I replied to this in another post.



b) where do you see that this concerns are not well implemented in the code
c) if you would like to modify #a, quickly describe the new purposes of the 
classes in your vision



DispatchContext becomes a lightweight container for objects that a 
service implementation needs. Instead of relatively-constant instances 
being kept inside a GenericDispatcher, a new instance is created 
on-the-fly whenever a service is invoked.




d) what are the methods/fields that you would like to move from DispatchContext



It's the other way around. I want to remove the DispatchContext 
reference from GenericDispatcher.





Thanks

Jacopo

PS: in general I also see a lot of code that should be cleaned in 
DispatchContext; for example, the initialization of the static map in the 
constructor, the method getAllServiceNames() that should be static, bad 
thread-safe implementation, probably the modelServiceMapByModel should not even 
be there...



Exactly. From my perspective, that code should be in ServiceDispatcher.






However, it will open up the possibility to improve the API. For example, 
instead of this service implementation:

public static MapString, Object myService(DispatchContext dctx, MapString, 
Object context) {
  Locale locale = (Locale) context.get(locale);
...

we could have:

public static MapString, Object myService(DispatchContext dctx) {
  Locale locale = dctx.getParameter(locale);
...


What do you think?


--
Adrian Crum
Sandglass Software
www.sandglass-software.com

Re: Discussion: Service Engine Refactoring

2014-08-31 Thread Pierre @GMail

That is a nice piece of explanation. Should be part of the documentation, if it 
is not already. 

Regards, 

Pierre 

Sent from my iPhone

 On 31 aug. 2014, at 11:56, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:
 
 
 On Aug 31, 2014, at 11:36 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:
 
 a) what is the original concern of DispatchContext and of GenericDispatcher
 
 This comes from this old but still interesting document: 
 http://ofbiz.apache.org/docs/services.html
 
 
 *Service Dispatcher*
 
 The Service Dispatcher handles dispatching services to the appropriate 
 Service Engine where it is then invoked. There is exactly one 
 ServiceDispatcher for each Entity Delegator. If there are multiple delegators 
 in an application there will also be multiple dispatchers. The 
 ServiceDispatcher is accessed via a LocalDispatcher. There can be many 
 LocalDispatchers associated with a ServiceDispatcher. Each LocalDispatcher is 
 uniquely named and contains its own list of service definitions. When 
 creating an instance of a LocalDispatcher, a DispatchContext is also created 
 and passed to the ServiceEngine.
 
 A LocalDispatcher is associated with an application. Applications never talk 
 directly to the ServiceDispatcher. The LocalDispatcher contains an API for 
 invoking services, which are routed through the ServiceDispather. However, 
 applications may be running in different threads than the actual 
 ServiceDispatcher, so it is left to the LocalDispatcher to keep a 
 DispatchContext which among other things keeps a reference to the 
 applications classloader.
 
 *Dispatch Context*
 
 The DispatchContext is created by the LocalDispatcher upon instantiation. 
 This is the runtime dispatcher context. It contains necessary information to 
 process services for each dispatcher. This context contains the reference to 
 each of the service definition files, the classloader which should be used 
 for invocation, a reference to the delegator and its dispatcher along with a 
 'bag' of user defined attributes. This context is passed on to each service 
 when invoked and is used by the dispatcher to determine the service's model.
 
 
 
 Jacopo

Re: [VOTE] [RELEASE] Apache OFBiz 11.04.06


+1

MD5 OK
Tests unsuccessful on Win7 (2 times, last one: ant clean-all run-install 
run-tests)
failures:
testReadWriteObject
testCountViews
 errors:
testRemoveByCondition
testRemoveByPK
testRemoveType
testCreateManyAndStoreAtOnce
testUpdateInventoryItemTransfer
Test OK on Unbuntu 13

Thanks Jacopo, sorry again for the regression

Jacques

Le 30/08/2014 12:51, Jacopo Cappellato a écrit :

This is the vote thread to release a new bug fix release for the release11.04 branch. 
This new release, Apache OFBiz 11.04.06 will supersede all the previous 
releases from the same branch.
The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-11.04.06.zip
* KEYS: text file with keys
* apache-ofbiz-11.04.06.zip.asc: the detached signature file
* apache-ofbiz-11.04.06.zip.md5, apache-ofbiz-11.04.06.zip.sha: hashes

Please download and test the zip file and its signatures (for instructions on 
testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 11.04.06
[ -1] do not release

This vote will be open for at least 3 days.
For more details about this process please read 
http://www.apache.org/foundation/voting.html

Kind Regards,

Jacopo

Re: [VOTE] [RELEASE] Apache OFBiz 12.04.05


+1

MD5 OK
Tests unsuccessful on Win7,
failures:
testForeignKeyRemove
testStoreByCondition
testMakeValue
errors:
testUpdateValue
testRemoveValue
testEntityCache
testAddMembersToTree
Test OK on Unbuntu 13

Jacques

Le 30/08/2014 13:27, Jacopo Cappellato a écrit :

This is the vote thread to release a new bug fix release for the release12.04 branch. 
This new release, Apache OFBiz 12.04.05 will supersede all the previous 
releases from the same branch.
The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-12.04.05.zip
* KEYS: text file with keys
* apache-ofbiz-12.04.05.zip.asc: the detached signature file
* apache-ofbiz-12.04.05.zip.md5, apache-ofbiz-12.04.05.zip.sha: hashes

Please download and test the zip file and its signatures (for instructions on 
testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 12.04.05
[ -1] do not release

This vote will be open for at least 3 days.
For more details about this process please read 
http://www.apache.org/foundation/voting.html

Kind Regards,

Jacopo

Re: Discussion: Service Engine Refactoring

That's fine. The opportunity will be there if anyone wants to explore 
it. It is not something I will push for.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 10:54 AM, Jacopo Cappellato wrote:


On Aug 31, 2014, at 10:50 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:


However, it will open up the possibility to improve the API. For example, 
instead of this service implementation:

public static MapString, Object myService(DispatchContext dctx, MapString, 
Object context) {
  Locale locale = (Locale) context.get(locale);
...

we could have:

public static MapString, Object myService(DispatchContext dctx) {
  Locale locale = dctx.getParameter(locale);
...


DispatchContext and the Map with input parameters have a completely different purpose and 
I don't think this would be an improvement per se. We will have to revisit 
this conversation at some point to be sure we are in the same page.

Jacopo

[jira] [Closed] (OFBIZ-5733) Update Derby to last 10.11.1.1 version (security fixes included)


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

Jacques Le Roux closed OFBIZ-5733.
--

   Resolution: Done
Fix Version/s: Upcoming Branch

Done at r1621581

 Update Derby to last 10.11.1.1 version (security fixes included)
 

 Key: OFBIZ-5733
 URL: https://issues.apache.org/jira/browse/OFBIZ-5733
 Project: OFBiz
  Issue Type: Task
  Components: framework
Affects Versions: 11.04.06, 12.04.05, 13.07.01, Upcoming Branch
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
  Labels: Derby
 Fix For: Upcoming Branch


 There are security issues fixed in this release though none seem important
 http://db.apache.org/derby/releases/release-10.11.1.1.cgi
 I have not verified yet if we need changes in OFBiz code (I would be 
 surprised) in order to update tho this Derby version
 Note: I like the way they show their release notes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Discussion: Service Engine Refactoring


For now there is only a link to services.html from the tutorial.
The best place to add another link seems 
https://cwiki.apache.org/confluence/display/OFBTECH/Service+Engine+Guide

Jacques

Le 31/08/2014 12:14, Pierre @GMail a écrit :

That is a nice piece of explanation. Should be part of the documentation, if it 
is not already.

Regards,

Pierre

Sent from my iPhone


On 31 aug. 2014, at 11:56, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:



On Aug 31, 2014, at 11:36 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

a) what is the original concern of DispatchContext and of GenericDispatcher

This comes from this old but still interesting document: 
http://ofbiz.apache.org/docs/services.html


*Service Dispatcher*

The Service Dispatcher handles dispatching services to the appropriate Service 
Engine where it is then invoked. There is exactly one ServiceDispatcher for 
each Entity Delegator. If there are multiple delegators in an application there 
will also be multiple dispatchers. The ServiceDispatcher is accessed via a 
LocalDispatcher. There can be many LocalDispatchers associated with a 
ServiceDispatcher. Each LocalDispatcher is uniquely named and contains its own 
list of service definitions. When creating an instance of a LocalDispatcher, a 
DispatchContext is also created and passed to the ServiceEngine.

A LocalDispatcher is associated with an application. Applications never talk 
directly to the ServiceDispatcher. The LocalDispatcher contains an API for 
invoking services, which are routed through the ServiceDispather. However, 
applications may be running in different threads than the actual 
ServiceDispatcher, so it is left to the LocalDispatcher to keep a 
DispatchContext which among other things keeps a reference to the applications 
classloader.

*Dispatch Context*

The DispatchContext is created by the LocalDispatcher upon instantiation. This 
is the runtime dispatcher context. It contains necessary information to process 
services for each dispatcher. This context contains the reference to each of 
the service definition files, the classloader which should be used for 
invocation, a reference to the delegator and its dispatcher along with a 'bag' 
of user defined attributes. This context is passed on to each service when 
invoked and is used by the dispatcher to determine the service's model.



Jacopo

Re: Discussion: Service Engine Refactoring


Here is some ASCII art that might help:

DispatchContext (a container for objects needed by service implementations)
  |
  |__ (references) LocalDispatcher (an application-specific service 
dispatcher)

 |
 |__ (delegates to) ServiceDispatcher
  |
  |__ (based on) Delegator



Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 10:36 AM, Jacopo Cappellato wrote:

Thank you Adrian,

please see inline:

On Aug 31, 2014, at 10:50 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:


Currently, the service engine classes are a bit muddled. GenericDispatcher (the 
default LocalDispatcher implementation) and DispatchContext have feature envy. 
Some functionality in DispatchContext belongs in ServiceDispatcher.

I would like to clean this up a bit and provide better separation of concerns. The 
service engine API will not change - the work will be done under the hood.

My hope is to get the code to a point where DispatchContext becomes less 
integral to its neighbors, and it becomes more of a single-use lightweight 
container. Again, this will not change the API at all.


I think it would help the other committers to provide feedback if you could (in 
just a few sentences) summarize the following:
a) what is the original concern of DispatchContext and of GenericDispatcher
b) where do you see that this concerns are not well implemented in the code
c) if you would like to modify #a, quickly describe the new purposes of the 
classes in your vision
d) what are the methods/fields that you would like to move from DispatchContext

Thanks

Jacopo

PS: in general I also see a lot of code that should be cleaned in 
DispatchContext; for example, the initialization of the static map in the 
constructor, the method getAllServiceNames() that should be static, bad 
thread-safe implementation, probably the modelServiceMapByModel should not even 
be there...



However, it will open up the possibility to improve the API. For example, 
instead of this service implementation:

public static MapString, Object myService(DispatchContext dctx, MapString, 
Object context) {
  Locale locale = (Locale) context.get(locale);
...

we could have:

public static MapString, Object myService(DispatchContext dctx) {
  Locale locale = dctx.getParameter(locale);
...


What do you think?


--
Adrian Crum
Sandglass Software
www.sandglass-software.com

Re: svn commit: r1621581 - in /ofbiz/trunk: LICENSE framework/entity/lib/jdbc/derby-10.10.2.0.jar framework/entity/lib/jdbc/derby-10.11.1.1.jar


I am not getting any test failures on Windows.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 11:18 AM, jler...@apache.org wrote:

Author: jleroux
Date: Sun Aug 31 10:18:38 2014
New Revision: 1621581

URL: http://svn.apache.org/r1621581
Log:
Upgrades Derby from derby-10.10.2.0.jar to derby-10.11.1.1.jar, tests OK (4 not 
relevant failures on Windows, we will get confirmation with Buildbot, or revert)

Added:
 ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar   (with props)
Removed:
 ofbiz/trunk/framework/entity/lib/jdbc/derby-10.10.2.0.jar
Modified:
 ofbiz/trunk/LICENSE

Modified: ofbiz/trunk/LICENSE
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/LICENSE?rev=1621581r1=1621580r2=1621581view=diff
==
--- ofbiz/trunk/LICENSE (original)
+++ ofbiz/trunk/LICENSE Sun Aug 31 10:18:38 2014
@@ -88,7 +88,7 @@ framework/catalina/lib/tomcat-7.0.55-tom
  framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli.jar
  framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli-adapters.jar
  framework/entity/lib/commons-dbcp2-2.0.1.jar
-framework/entity/lib/jdbc/derby-10.10.2.0.jar
+framework/entity/lib/jdbc/derby-10.11.1.1.jar
  framework/service/lib/axiom-api-1.2.9.jar
  framework/service/lib/axiom-impl-1.2.9.jar
  framework/service/lib/axis2-kernel-1.5.2.jar

Added: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar?rev=1621581view=auto
==
Binary file - no diff available.

Propchange: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
--
 svn:mime-type = application/octet-stream

Re: svn commit: r1621581 - in /ofbiz/trunk: LICENSE framework/entity/lib/jdbc/derby-10.10.2.0.jar framework/entity/lib/jdbc/derby-10.11.1.1.jar


Thanks, good news, I don't know why I got them, like I did with 12 and 11 
releases :/

Jacques

Le 31/08/2014 12:50, Adrian Crum a écrit :

I am not getting any test failures on Windows.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 11:18 AM, jler...@apache.org wrote:

Author: jleroux
Date: Sun Aug 31 10:18:38 2014
New Revision: 1621581

URL: http://svn.apache.org/r1621581
Log:
Upgrades Derby from derby-10.10.2.0.jar to derby-10.11.1.1.jar, tests OK (4 not relevant failures on Windows, we will get confirmation with 
Buildbot, or revert)


Added:
 ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar (with props)
Removed:
 ofbiz/trunk/framework/entity/lib/jdbc/derby-10.10.2.0.jar
Modified:
 ofbiz/trunk/LICENSE

Modified: ofbiz/trunk/LICENSE
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/LICENSE?rev=1621581r1=1621580r2=1621581view=diff
==
--- ofbiz/trunk/LICENSE (original)
+++ ofbiz/trunk/LICENSE Sun Aug 31 10:18:38 2014
@@ -88,7 +88,7 @@ framework/catalina/lib/tomcat-7.0.55-tom
  framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli.jar
framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli-adapters.jar
  framework/entity/lib/commons-dbcp2-2.0.1.jar
-framework/entity/lib/jdbc/derby-10.10.2.0.jar
+framework/entity/lib/jdbc/derby-10.11.1.1.jar
  framework/service/lib/axiom-api-1.2.9.jar
  framework/service/lib/axiom-impl-1.2.9.jar
  framework/service/lib/axis2-kernel-1.5.2.jar

Added: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar?rev=1621581view=auto
==
Binary file - no diff available.

Propchange: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
--
 svn:mime-type = application/octet-stream

Re: svn commit: r1621581 - in /ofbiz/trunk: LICENSE framework/entity/lib/jdbc/derby-10.10.2.0.jar framework/entity/lib/jdbc/derby-10.11.1.1.jar


Ah forgot, also OK on Buildbot 
http://ci.apache.org/projects/ofbiz/logs/trunk/html/

I hope Gavin will find some time to cure our RAT report
http://ci.apache.org/builders/ofbiz-trunk/builds/249
https://issues.apache.org/jira/browse/INFRA-8181

Jacques

Le 31/08/2014 13:19, Jacques Le Roux a écrit :

Thanks, good news, I don't know why I got them, like I did with 12 and 11 
releases :/

Jacques

Le 31/08/2014 12:50, Adrian Crum a écrit :

I am not getting any test failures on Windows.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 11:18 AM, jler...@apache.org wrote:

Author: jleroux
Date: Sun Aug 31 10:18:38 2014
New Revision: 1621581

URL: http://svn.apache.org/r1621581
Log:
Upgrades Derby from derby-10.10.2.0.jar to derby-10.11.1.1.jar, tests OK (4 not relevant failures on Windows, we will get confirmation with 
Buildbot, or revert)


Added:
 ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar (with props)
Removed:
 ofbiz/trunk/framework/entity/lib/jdbc/derby-10.10.2.0.jar
Modified:
 ofbiz/trunk/LICENSE

Modified: ofbiz/trunk/LICENSE
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/LICENSE?rev=1621581r1=1621580r2=1621581view=diff
==
--- ofbiz/trunk/LICENSE (original)
+++ ofbiz/trunk/LICENSE Sun Aug 31 10:18:38 2014
@@ -88,7 +88,7 @@ framework/catalina/lib/tomcat-7.0.55-tom
  framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli.jar
framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli-adapters.jar
  framework/entity/lib/commons-dbcp2-2.0.1.jar
-framework/entity/lib/jdbc/derby-10.10.2.0.jar
+framework/entity/lib/jdbc/derby-10.11.1.1.jar
  framework/service/lib/axiom-api-1.2.9.jar
  framework/service/lib/axiom-impl-1.2.9.jar
  framework/service/lib/axis2-kernel-1.5.2.jar

Added: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar?rev=1621581view=auto
==
Binary file - no diff available.

Propchange: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
--
 svn:mime-type = application/octet-stream

Re: svn commit: r1621581 - in /ofbiz/trunk: LICENSE framework/entity/lib/jdbc/derby-10.10.2.0.jar framework/entity/lib/jdbc/derby-10.11.1.1.jar


Actually it was this one http://ci.apache.org/builders/ofbiz-trunk/builds/251

Anyway

Jacques

Le 31/08/2014 13:22, Jacques Le Roux a écrit :

Ah forgot, also OK on Buildbot 
http://ci.apache.org/projects/ofbiz/logs/trunk/html/

I hope Gavin will find some time to cure our RAT report
http://ci.apache.org/builders/ofbiz-trunk/builds/249
https://issues.apache.org/jira/browse/INFRA-8181

Jacques

Le 31/08/2014 13:19, Jacques Le Roux a écrit :

Thanks, good news, I don't know why I got them, like I did with 12 and 11 
releases :/

Jacques

Le 31/08/2014 12:50, Adrian Crum a écrit :

I am not getting any test failures on Windows.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/31/2014 11:18 AM, jler...@apache.org wrote:

Author: jleroux
Date: Sun Aug 31 10:18:38 2014
New Revision: 1621581

URL: http://svn.apache.org/r1621581
Log:
Upgrades Derby from derby-10.10.2.0.jar to derby-10.11.1.1.jar, tests OK (4 not relevant failures on Windows, we will get confirmation with 
Buildbot, or revert)


Added:
ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar (with props)
Removed:
ofbiz/trunk/framework/entity/lib/jdbc/derby-10.10.2.0.jar
Modified:
 ofbiz/trunk/LICENSE

Modified: ofbiz/trunk/LICENSE
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/LICENSE?rev=1621581r1=1621580r2=1621581view=diff
==
--- ofbiz/trunk/LICENSE (original)
+++ ofbiz/trunk/LICENSE Sun Aug 31 10:18:38 2014
@@ -88,7 +88,7 @@ framework/catalina/lib/tomcat-7.0.55-tom
framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli.jar
framework/catalina/lib/tomcat-extras-7.0.55-tomcat-juli-adapters.jar
  framework/entity/lib/commons-dbcp2-2.0.1.jar
-framework/entity/lib/jdbc/derby-10.10.2.0.jar
+framework/entity/lib/jdbc/derby-10.11.1.1.jar
  framework/service/lib/axiom-api-1.2.9.jar
  framework/service/lib/axiom-impl-1.2.9.jar
  framework/service/lib/axis2-kernel-1.5.2.jar

Added: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar?rev=1621581view=auto
==
Binary file - no diff available.

Propchange: ofbiz/trunk/framework/entity/lib/jdbc/derby-10.11.1.1.jar
--
 svn:mime-type = application/octet-stream

[jira] [Commented] (OFBIZ-5729) ofbiz hangs on installing tenant database

2014-08-31 Thread Wai (JIRA)


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

Wai commented on OFBIZ-5729:


Hello,
Any status on integrating this patch???
Thanks

 ofbiz hangs on installing tenant database 
 --

 Key: OFBIZ-5729
 URL: https://issues.apache.org/jira/browse/OFBIZ-5729
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Wai
Assignee: Adrian Crum
 Attachments: ofbiz console output-with bug.log, ofbiz console 
 output-with fix.log, ofbiz-5729.patch, ofbiz-5729.patch


 When installing data into a tenant database, ofbiz hangs.
 Using the following command line.
 $ ant load-tenant-data-readers -Ddata-readers=seed -DtenantId=DEMO1
 The problem is that ofbiz uses DelegatorFactory.getDelegator() to find/create 
 the tenant delegator, asynchronously, for the target tenant database using a 
 single daemon thread.  As part of the tenant delegator creation, it needs to 
 find/create a base delegator.  When the base delegator is intially absent, 
 ofbiz will block trying to create one by using the same daemon thread--which 
 is already being used.  Hence, ofbiz is deadlocked.
 The solution is to make sure that a base delegator is always created first 
 before a find/create tenant delegator is attempted.



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

Re: Discussion: Service Engine Refactoring