[jira] [Comment Edited] (OFBIZ-11313) Parsing included controller files eagerly
[
https://issues.apache.org/jira/browse/OFBIZ-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17005209#comment-17005209
]
Mathieu Lirzin edited comment on OFBIZ-11313 at 12/30/19 8:59 AM:
--
I will commit
[^0001-Improved-Retrieve-the-included-controller-files-eage.patch] and
[^0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch] tomorrow
unless somebody objects.
Those patches can be applied using {{git am XXX.patch}} and must be applied in
order.
was (Author: mthl):
I will commit
[^0001-Improved-Retrieve-the-included-controller-files-eage.patch] and
[^0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch] tomorrow
unless somebody objects.
Those patches can be applied using {{git am XXX.patch}} and should be applied
in order.
> Parsing included controller files eagerly
> -
>
> Key: OFBIZ-11313
> URL: https://issues.apache.org/jira/browse/OFBIZ-11313
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> 0001-Improved-Retrieve-the-included-controller-files-eage.patch,
> 0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch
>
>
> Controller configuration files have the ability to include other controllers
> which can be useful to make the controller more modular and potentially
> reusable.
> Currently included controller files are retrieved lazily when reading the
> properties from a controller configuration. This technique avoids unnecessary
> work at startup but in this concrete case the gain in negligeable and has the
> drawback of requiring error handling everytime a property is read which is
> cumbersome.
> As a consequence it would be better to parse included files eagerly at
> startup time to be able to detect inclusion errors early and relaxing the
> error handling when reading properties since all the sensible work will be
> done when instantiating the {{ControllerConfig}} object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11313) Parsing included controller files eagerly
[
https://issues.apache.org/jira/browse/OFBIZ-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17005209#comment-17005209
]
Mathieu Lirzin commented on OFBIZ-11313:
I will commit
[^0001-Improved-Retrieve-the-included-controller-files-eage.patch] and
[^0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch] tomorrow
unless somebody objects.
Those patches can be applied using {{git am XXX.patch}} and should be applied
in order.
> Parsing included controller files eagerly
> -
>
> Key: OFBIZ-11313
> URL: https://issues.apache.org/jira/browse/OFBIZ-11313
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> 0001-Improved-Retrieve-the-included-controller-files-eage.patch,
> 0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch
>
>
> Controller configuration files have the ability to include other controllers
> which can be useful to make the controller more modular and potentially
> reusable.
> Currently included controller files are retrieved lazily when reading the
> properties from a controller configuration. This technique avoids unnecessary
> work at startup but in this concrete case the gain in negligeable and has the
> drawback of requiring error handling everytime a property is read which is
> cumbersome.
> As a consequence it would be better to parse included files eagerly at
> startup time to be able to detect inclusion errors early and relaxing the
> error handling when reading properties since all the sensible work will be
> done when instantiating the {{ControllerConfig}} object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11313) Parsing included controller files eagerly
[
https://issues.apache.org/jira/browse/OFBIZ-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11313:
---
Attachment: 0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch
0001-Improved-Retrieve-the-included-controller-files-eage.patch
> Parsing included controller files eagerly
> -
>
> Key: OFBIZ-11313
> URL: https://issues.apache.org/jira/browse/OFBIZ-11313
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> 0001-Improved-Retrieve-the-included-controller-files-eage.patch,
> 0002-Improved-Remove-RequestHandler-ControllerConfig-wrap.patch
>
>
> Controller configuration files have the ability to include other controllers
> which can be useful to make the controller more modular and potentially
> reusable.
> Currently included controller files are retrieved lazily when reading the
> properties from a controller configuration. This technique avoids unnecessary
> work at startup but in this concrete case the gain in negligeable and has the
> drawback of requiring error handling everytime a property is read which is
> cumbersome.
> As a consequence it would be better to parse included files eagerly at
> startup time to be able to detect inclusion errors early and relaxing the
> error handling when reading properties since all the sensible work will be
> done when instantiating the {{ControllerConfig}} object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OFBIZ-11313) Parsing included controller files eagerly
Mathieu Lirzin created OFBIZ-11313:
--
Summary: Parsing included controller files eagerly
Key: OFBIZ-11313
URL: https://issues.apache.org/jira/browse/OFBIZ-11313
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Trunk
Reporter: Mathieu Lirzin
Assignee: Mathieu Lirzin
Controller configuration files have the ability to include other controllers
which can be useful to make the controller more modular and potentially
reusable.
Currently included controller files are retrieved lazily when reading the
properties from a controller configuration. This technique avoids unnecessary
work at startup but in this concrete case the gain in negligeable and has the
drawback of requiring error handling everytime a property is read which is
cumbersome.
As a consequence it would be better to parse included files eagerly at startup
time to be able to detect inclusion errors early and relaxing the error
handling when reading properties since all the sensible work will be done when
instantiating the {{ControllerConfig}} object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11007) REST: adding segmented URI support
[
https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004807#comment-17004807
]
Mathieu Lirzin edited comment on OFBIZ-11007 at 12/30/19 8:30 AM:
--
Hello [~nmalin],
The approach we followed with [~artemiy] was to intentionally not provide any
guarantee on the request-map resolution algorithm in the context of
ambiguities, meaning when multiple request-maps are matching the same HTTP
request URI. Our assumption was that ambiguous routes should not be used to
simplify reasoning/debugging. A limitation of the current implementation is
that we currently don't detect/report those ambiguities, we simply choose one.
Our approach is debatable and for example the JAX-RS specification which serves
as a standard for Java REST APIs [specifies a precedence order when matching
URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2].
So I am not strongly opposed to specifying a resolution order in OFBiz as you
proposed in [^OFBIZ-11007_refactor-entitymaint.patch], with the condition that
it follows a standard and documented algorithm like for example the one from
JAX-RS.
Regarding the particular case of entities, a simple way to avoid ambiguities in
your example would be to use different separators like for example:
{code:java}
entity-list -> entitymaint
entity/{entityName} -> FindGeneric
entity/{entityName}/{pkValues: .*} -> ViewGeneric
entity-edit/{entityName} -> edit form
entity-edit/{entityName}/{pkValues: .*} -> edit form
entity-relations/{entityName} -> ViewRelation
{code}
If you really want to use {{/}} while removing ambiguities you can use regular
expression in URI templates to prevent {{entity/\{entityName\}}} to match
{{/entity/list}} you should be able to replace it with something like
{{entity/\{name: (?!list).*\}}} to prevent the match (not tested). However I
don't recommend that solution because it requires understanding an advanced
feature of Java regexp.
Thanks for working on that.
was (Author: mthl):
Hello [~nmalin],
The approach we followed with [~artemiy] was to intentionally not provide any
guarantee on the request-map resolution algorithm in the context of
ambiguities, meaning when multiple request-maps are matching the same HTTP
request URI. Our assumption was that ambiguous routes should not be used to
simplify reasoning/debugging. A limitation of the current implementation is
that we currently don't detect/report those ambiguities, we simply choose one.
Our approach is debatable and for example the JAX-RS specification which serves
as a standard for Java REST APIs [specifies a precedence order when matching
URI|https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-eval-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1577630576_4b24b6231d72cf225332a21ec2aaf761#subsection.3.7.2].
So I am not strongly opposed to specifying a resolution order in OFBiz as you
proposed in [^OFBIZ-11007_refactor-entitymaint.patch], with the condition that
it follows a standard and documented algorithm like for example the one from
JAX-RS.
Regarding the particular case of entities, a simple way to avoid ambiguities in
your example would be to use different separators like for example:
{code:java}
entity-list -> entitymaint
entity/{entityName} -> FindGeneric
entity/{entityName}/{pkValues: .*} -> ViewGeneric
entity-edit/{entityName} -> edit form
entity-edit/{entityName}/{pkValues: .*} -> edit form
entity-relations/{entityName} -> ViewRelation
{code}
If you really want to use {{/}} while removing ambiguities you can use regular
expression in URI templates to prevent {{entity/\{entityName\}}} to match
{{/entity/list}} you should be able to replace it with something like
{{entity/\{name:(?!list).*\}}} to prevent the match (not tested). However I
don't recommend that solution because it requires understanding an advanced
feature of Java regexp.
Thanks for working on that.
> REST: adding segmented URI support
> --
>
> Key: OFBIZ-11007
> URL: https://issues.apache.org/jira/browse/OFBIZ-11007
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
> Environment:
>Reporter: Artemiy Rozovyk
>Assignee: Nicolas Malin
>Priority: Minor
> Labels: REST, URI
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-11007_refactor-entitymaint.patch,
> OFBIZ-11007_refactor-entitymaint.patch, entitymaint_example.patch,
> restful_URIs.patch
>
>
> Following the discussion on making OFBiz RESTful OFBIZ-4274 i implemented the
> support of segmented URIs without interfering with current mechanisms of
