[jira] [Commented] (OFBIZ-11310) JSON renderer for screen/menu/form
[ https://issues.apache.org/jira/browse/OFBIZ-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060551#comment-17060551 ] Mathieu Lirzin commented on OFBIZ-11310: Given the current situation I revoke my proposal to review your work. Sorry for dropping the ball here. The best next move for you would be to ask on ML for someone else to review this work, if nobody step up feel free to go ahead and commit. Kind regards > JSON renderer for screen/menu/form > --- > > Key: OFBIZ-11310 > URL: https://issues.apache.org/jira/browse/OFBIZ-11310 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Olivier Heintz >Priority: Minor > Attachments: FrontJsFormRenderer.java, FrontJsMenuRenderer.java, > FrontJsOutput.java, FrontJsScreenRenderer.java, > FrontJsScreenViewHandler.java, FrontJsTreeRenderer.java, OFBIZ-11310.patch > > > In a POC approach for using a SPA framework for GUI in OFBiz, json renderer > have been developed. > This Jira could be used to do code review on these renderer. > Currently, these renderer are on a V0 situation, it's a work in process > situation. After mailing-list discussion with mathieu we decide to go to a > V0.1 by 2-3 tasks > * add some javadoc each time it's necessary or needed > * remove all comment code or explain the decision waiting to activate or > remove the code > * do checkstyle > On first step, code will be with only what is used in a use case (no code for > tag not currently manage). > Json renderer are part of vuejs-portal plugin, in ofbizextra gitlab > (https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/vuejsPortal), so > commit are done on it, and mailing-list with these commit [are > ofbizextra-com...@lists.sourceforge.net.|mailto:are%c2%a0ofbizextra-com...@lists.sourceforge.net.] > But we will publish an update on this Jira each week there are some > modifications on renderer files > This task will take some time because it will used to do a complete code > review, not only in renderer but in vuejs component too, and so complete > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-11310) JSON renderer for screen/menu/form
[ https://issues.apache.org/jira/browse/OFBIZ-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin reassigned OFBIZ-11310: -- Assignee: (was: Mathieu Lirzin) > JSON renderer for screen/menu/form > --- > > Key: OFBIZ-11310 > URL: https://issues.apache.org/jira/browse/OFBIZ-11310 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Olivier Heintz >Priority: Minor > Attachments: FrontJsFormRenderer.java, FrontJsMenuRenderer.java, > FrontJsOutput.java, FrontJsScreenRenderer.java, > FrontJsScreenViewHandler.java, FrontJsTreeRenderer.java, OFBIZ-11310.patch > > > In a POC approach for using a SPA framework for GUI in OFBiz, json renderer > have been developed. > This Jira could be used to do code review on these renderer. > Currently, these renderer are on a V0 situation, it's a work in process > situation. After mailing-list discussion with mathieu we decide to go to a > V0.1 by 2-3 tasks > * add some javadoc each time it's necessary or needed > * remove all comment code or explain the decision waiting to activate or > remove the code > * do checkstyle > On first step, code will be with only what is used in a use case (no code for > tag not currently manage). > Json renderer are part of vuejs-portal plugin, in ofbizextra gitlab > (https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/vuejsPortal), so > commit are done on it, and mailing-list with these commit [are > ofbizextra-com...@lists.sourceforge.net.|mailto:are%c2%a0ofbizextra-com...@lists.sourceforge.net.] > But we will publish an update on this Jira each week there are some > modifications on renderer files > This task will take some time because it will used to do a complete code > review, not only in renderer but in vuejs component too, and so complete > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11205) Move Groovy scripts from /groovyScripts/ to /src/main/groovy/
[
https://issues.apache.org/jira/browse/OFBIZ-11205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028452#comment-17028452
]
Mathieu Lirzin commented on OFBIZ-11205:
Hello,
Having dynamic development capabilities and distributing code inside a jar are
not conflicting requirements as long as the loading mechanism can access the
source files. In a development environment you do not use a jar directly, the
build tool (gradle) use sub-directories inside the {{build}} directory and make
the classpath point to those directories. {{gradlew --continuous}} ensures that
the {{build}} directory is in sync with the source one which enable dynamic
development.
Having all the framework code and resources inside the jar is just a commodity
of distribution facilitating the execution and extension of OFBiz outside of
the context of the framework development.
Does it help understanding the absence of conflicts?
> Move Groovy scripts from /groovyScripts/ to /src/main/groovy/
> --
>
> Key: OFBIZ-11205
> URL: https://issues.apache.org/jira/browse/OFBIZ-11205
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> As mentioned in this discussion: https://markmail.org/message/2grqu63yvfpvxzz6
> {quote}
> Here is the (simple) plan:
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it like
> that. It will continuously build on any changes in Gradle sourcesets
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
> I'm sure there are other benefits to follow "the common convention of putting
> groovy compiled sources in ${COMPONENT}/src/main/groovy.", as suggested
> Mathieu.
> {quote}
> [~paulfoxworthy] added
> bq. This will encourage and accelerate moving Java services to Groovy, I
> think.
> And [~gil portenseigne]:
> bq. The main advantage I see is, beside compilation, the integration in your
> IDE, that was not optimum, and the possibility to re-use methods from these
> script migrated to explicit classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11310) JSON renderer for screen/menu/form
[ https://issues.apache.org/jira/browse/OFBIZ-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013595#comment-17013595 ] Mathieu Lirzin commented on OFBIZ-11310: Sorry Olivier for the late reply I did not notice that you actually opened a ticket for the JSON screen renderer. To avoid this kind of issue next time, feel free to either send a message on the mailing list on the associated thread linking the discussion with the ticket, or you can ping people with a [~mthl] mention. In order to start the review, it will help me if you could provide a patch combining the newly added files and defining the location inside the framework where those file will be put. Thanks > JSON renderer for screen/menu/form > --- > > Key: OFBIZ-11310 > URL: https://issues.apache.org/jira/browse/OFBIZ-11310 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Olivier Heintz >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: FrontJsFormRenderer.java, FrontJsMenuRenderer.java, > FrontJsOutput.java, FrontJsScreenRenderer.java, > FrontJsScreenViewHandler.java, FrontJsTreeRenderer.java > > > In a POC approach for using a SPA framework for GUI in OFBiz, json renderer > have been developed. > This Jira could be used to do code review on these renderer. > Currently, these renderer are on a V0 situation, it's a work in process > situation. After mailing-list discussion with mathieu we decide to go to a > V0.1 by 2-3 tasks > * add some javadoc each time it's necessary or needed > * remove all comment code or explain the decision waiting to activate or > remove the code > * do checkstyle > On first step, code will be with only what is used in a use case (no code for > tag not currently manage). > Json renderer are part of vuejs-portal plugin, in ofbizextra gitlab > (https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/vuejsPortal), so > commit are done on it, and mailing-list with these commit [are > ofbizextra-com...@lists.sourceforge.net.|mailto:are%c2%a0ofbizextra-com...@lists.sourceforge.net.] > But we will publish an update on this Jira each week there are some > modifications on renderer files > This task will take some time because it will used to do a complete code > review, not only in renderer but in vuejs component too, and so complete > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-11310) JSON renderer for screen/menu/form
[ https://issues.apache.org/jira/browse/OFBIZ-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin reassigned OFBIZ-11310: -- Assignee: Mathieu Lirzin > JSON renderer for screen/menu/form > --- > > Key: OFBIZ-11310 > URL: https://issues.apache.org/jira/browse/OFBIZ-11310 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Olivier Heintz >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: FrontJsFormRenderer.java, FrontJsMenuRenderer.java, > FrontJsOutput.java, FrontJsScreenRenderer.java, > FrontJsScreenViewHandler.java, FrontJsTreeRenderer.java > > > In a POC approach for using a SPA framework for GUI in OFBiz, json renderer > have been developed. > This Jira could be used to do code review on these renderer. > Currently, these renderer are on a V0 situation, it's a work in process > situation. After mailing-list discussion with mathieu we decide to go to a > V0.1 by 2-3 tasks > * add some javadoc each time it's necessary or needed > * remove all comment code or explain the decision waiting to activate or > remove the code > * do checkstyle > On first step, code will be with only what is used in a use case (no code for > tag not currently manage). > Json renderer are part of vuejs-portal plugin, in ofbizextra gitlab > (https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/vuejsPortal), so > commit are done on it, and mailing-list with these commit [are > ofbizextra-com...@lists.sourceforge.net.|mailto:are%c2%a0ofbizextra-com...@lists.sourceforge.net.] > But we will publish an update on this Jira each week there are some > modifications on renderer files > This task will take some time because it will used to do a complete code > review, not only in renderer but in vuejs component too, and so complete > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013587#comment-17013587 ] Mathieu Lirzin commented on OFBIZ-11296: You are right that your anwser is containing points specific to this issue however they are based on general principles (stability for production, backward compatibility, relation to community approval). Those principles are too far from my perspective/requirements as a developer trying to make OFBiz better, that I cannot see a way to resolve this specific issue without discussing the principles first. > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch, > OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11007) REST: adding segmented URI support
[
https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012712#comment-17012712
]
Mathieu Lirzin commented on OFBIZ-11007:
I did not dig much, I have first found
https://stackoverflow.com/questions/8054165/using-put-method-in-html-form which
gave me the impression that there was a consensus on this convention but that
is not backed by statistics.
Regarding Java frameworks, Spring uses this convention too
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/filter/reactive/HiddenHttpMethodFilter.html
> 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,
> 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 URI
> resolution nor with _overrideView()_ feature.
> Combined with work on associating URIs and HTTP methods done by [~mthl] in
> OFBIZ-10438 , we are now able to provide RESTful APIs as follows:
> {code:java}
>
> ...
>
> ...
>
> ...
> {code}
> After we matched a request-map having parametrized URI as in
> {code:java}
> uri="foo/bar/{baz}"
> {code}
> the value is available inside the request attributes with the corresponding
> key (here _"baz"_)
> The *restful_URIs.patch* allows segmented URI support.
> The *entitymaint_example.patch* is a modified _entitymaint_ part that serves
> as an example of possible application of new system.
> Any questions or comments are welcomed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11007) REST: adding segmented URI support
[
https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012555#comment-17012555
]
Mathieu Lirzin commented on OFBIZ-11007:
Hello Nicolas,
A bit late, but I have forgot to suggest the use of "_method" instead of
"restMethod" for the hidden field containing the actual request method that
should be effectively used in the controller. This naming convention is not
specified in any standard but seems [used in other web
frameworks|https://laravel.com/docs/4.2/html#opening-a-form].
> 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,
> 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 URI
> resolution nor with _overrideView()_ feature.
> Combined with work on associating URIs and HTTP methods done by [~mthl] in
> OFBIZ-10438 , we are now able to provide RESTful APIs as follows:
> {code:java}
>
> ...
>
> ...
>
> ...
> {code}
> After we matched a request-map having parametrized URI as in
> {code:java}
> uri="foo/bar/{baz}"
> {code}
> the value is available inside the request attributes with the corresponding
> key (here _"baz"_)
> The *restful_URIs.patch* allows segmented URI support.
> The *entitymaint_example.patch* is a modified _entitymaint_ part that serves
> as an example of possible application of new system.
> Any questions or comments are welcomed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009191#comment-17009191
]
Mathieu Lirzin commented on OFBIZ-11315:
As explained by Jacques, the --graph option is very lightweight utility
exploiting the functionality of the graph traversal code that is already used
when loading components.
This tool is useful to have in the core because it enables the management of an
important set of plugins that depend on each others and will likely require
some analysis/debugging. One motivation was to have a unified view of the
components like what is provided partially by component-load.xml files. The
difference is that the graph representation have better semantics because it
represents faithfully the partially ordered relation of component dependency
which is missing from component-load.xml.
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch,
> OFBIZ-11315-complete.patch,
> OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch,
> ofbiz.dot
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008186#comment-17008186 ] Mathieu Lirzin commented on OFBIZ-11296: This explains your point of view more clearly. As I understand it your points are mainly about general principles regarding how framework evolutions should be handled so I will respond on the mailing list instead of this specific ticket. > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch, > OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11296) Use 'depends-on' everywhere
[
https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007573#comment-17007573
]
Mathieu Lirzin edited comment on OFBIZ-11296 at 1/3/20 3:38 PM:
Hello I have included
[^OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch] which
fixes the regression where people were not able to add a custom
{{component-load.xml}} files in a directory without getting "depends-on"
attributes ignored. I will commit that fix in 3 days if nobody objects.
Regarding
[^OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch]
which replaces usages of {{component-load.xml}} files in framework/applications
directories with {{depends-on}} declarations and have been reverted because of
the "regression" described above, if [~mbrohl] (or others) does not provides a
convincing explanation (which has been asked multiple times) why they consider
the ability to mess with framework/applications {{component-load.xml}} a
feature and not an implementation detail, I will recommit it in 3 days too.
was (Author: mthl):
Hello I have included
[^OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch] which
fixes the regression where people we not able to add a custom
{{component-load.xml}} files in a directory without getting "depends-on"
attributes ignored. I will commit that fix in 3 days if nobody objects.
Regarding
[^OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch]
which replaces usages of {{component-load.xml}} files in framework/applications
directories with {{depends-on}} declarations and have been reverted because of
the "regression" described above, if [~mbrohl] (or others) does not provides a
convincing explanation (which has been asked multiple times) why they consider
to ability to mess with framework/applications {{component-load.xml}} a feature
and not an implementation detail, I will recommit it in 3 days too.
> Use 'depends-on' everywhere
> ---
>
> Key: OFBIZ-11296
> URL: https://issues.apache.org/jira/browse/OFBIZ-11296
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments:
> OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch,
> OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch
>
>
> We currently have two ways to define component loading order. Either
> by using ‘depends-on’ attribute in “component-config.xml” or by adding
> a “component-load.xml” file at the root of a component directory.
> “depends-on” is more flexible because it handles partial ordering when
> “component-load.xml” defines a total order which is not necessarily
> meaningful, so it is better to rely only “depends-on”.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11296) Use 'depends-on' everywhere
[
https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007573#comment-17007573
]
Mathieu Lirzin commented on OFBIZ-11296:
Hello I have included
[^OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch] which
fixes the regression where people we not able to add a custom
{{component-load.xml}} files in a directory without getting "depends-on"
attributes ignored. I will commit that fix in 3 days if nobody objects.
Regarding
[^OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch]
which replaces usages of {{component-load.xml}} files in framework/applications
directories with {{depends-on}} declarations and have been reverted because of
the "regression" described above, if [~mbrohl] (or others) does not provides a
convincing explanation (which has been asked multiple times) why they consider
to ability to mess with framework/applications {{component-load.xml}} a feature
and not an implementation detail, I will recommit it in 3 days too.
> Use 'depends-on' everywhere
> ---
>
> Key: OFBIZ-11296
> URL: https://issues.apache.org/jira/browse/OFBIZ-11296
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments:
> OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch,
> OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch
>
>
> We currently have two ways to define component loading order. Either
> by using ‘depends-on’ attribute in “component-config.xml” or by adding
> a “component-load.xml” file at the root of a component directory.
> “depends-on” is more flexible because it handles partial ordering when
> “component-load.xml” defines a total order which is not necessarily
> meaningful, so it is better to rely only “depends-on”.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11296: --- Attachment: OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch, > OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin reopened OFBIZ-11296: Assignee: Mathieu Lirzin > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007477#comment-17007477
]
Mathieu Lirzin commented on OFBIZ-11315:
Hello [~jleroux] and [~pierresmits],
I have included
[^OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch]
which is using the standard format.
I am referencing this commit
[aae1c8a8f5fed7de717290c938297be62c0460fa|https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=commit;h=aae1c8a8f5fed7de717290c938297be62c0460fa]
in the description
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch,
> OFBIZ-11315-complete.patch,
> OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11315:
---
Attachment:
OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch,
> OFBIZ-11315-complete.patch,
> OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007404#comment-17007404
]
Mathieu Lirzin edited comment on OFBIZ-11315 at 1/3/20 10:54 AM:
-
I have included [^0001-Implemented-Add-graph-option.patch] which implements
that feature.
This patch must be applied after the ones from OFBIZ-11314 with {{git am
XXX.patch}}
was (Author: mthl):
I have included [^0001-Implemented-Add-graph-option.patch] which implements
that feature.
This patch must be applied after the one from OFBIZ-11314 with {{git am
XXX.patch}}
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007404#comment-17007404
]
Mathieu Lirzin commented on OFBIZ-11315:
I have included [^0001-Implemented-Add-graph-option.patch] which implements
that feature.
This patch must be applied after the one from OFBIZ-11314 with {{git am
XXX.patch}}
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11315:
---
Attachment: 0001-Implemented-Add-graph-option.patch
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11315:
---
Description:
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{code}
cat ofbiz.dot | dot -T png -o ofbiz.png
{code}
Currently there is no dependency relationship specified by components but to
check the kind of input produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
was:
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{code}
cat ofbiz.dot | dot -T png -o ofbiz.png
{code}
Currently there is not dependency relationship specified by components but to
check the kind of input produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of input produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11315:
---
Description:
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{code}
cat ofbiz.dot | dot -T png -o ofbiz.png
{code}
Currently there is not dependency relationship specified by components but to
check the kind of input produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
was:
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{{cat ofbiz.dot | dot -T png -o ofbiz.png}}
Currently there is not dependency relationship specified by components but to
check the kind of input produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is not dependency relationship specified by components but to
> check the kind of input produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11315:
---
Description:
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{code}
cat ofbiz.dot | dot -T png -o ofbiz.png
{code}
Currently there is no dependency relationship specified by components but to
check the kind of graph is produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
was:
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{code}
cat ofbiz.dot | dot -T png -o ofbiz.png
{code}
Currently there is no dependency relationship specified by components but to
check the kind of input produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OFBIZ-11315) Add “--graph” option
Mathieu Lirzin created OFBIZ-11315:
--
Summary: Add “--graph” option
Key: OFBIZ-11315
URL: https://issues.apache.org/jira/browse/OFBIZ-11315
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: Trunk
Reporter: Mathieu Lirzin
Assignee: Mathieu Lirzin
In order to inspect what components are loaded by OFBiz and their dependency
relationship, it is convenient to have a visual graph representation.
{code}
gradlew "ofbiz --graph"
{code}
will output a {{ofbiz.dot}} file that can be processed with Graphviz:
{{cat ofbiz.dot | dot -T png -o ofbiz.png}}
Currently there is not dependency relationship specified by components but to
check the kind of input produced it is possible to revert commit
aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11314) Avoid stack overflow in the presence of cycles in controller inclusion
[ https://issues.apache.org/jira/browse/OFBIZ-11314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007334#comment-17007334 ] Mathieu Lirzin commented on OFBIZ-11314: I have updated [^0001-Improved-Rewrite-Digraph.patch] to fix a false positive cycle detection. > Avoid stack overflow in the presence of cycles in controller inclusion > -- > > Key: OFBIZ-11314 > URL: https://issues.apache.org/jira/browse/OFBIZ-11314 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: 0001-Improved-Rewrite-Digraph.patch, > 0001-Improved-Rewrite-Digraph.patch, > 0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch > > > The inclusion of controller configuration files can lead to inclusion cycles > which are not safely handled, because they can lead to infinite recursion > that end up in stack overflow exception. > A very basic form of cycle is controllers A and B which includes each other. > I would be better to check the inclusion cycles and report an appropriate > error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11314) Avoid stack overflow in the presence of cycles in controller inclusion
[ https://issues.apache.org/jira/browse/OFBIZ-11314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11314: --- Attachment: 0001-Improved-Rewrite-Digraph.patch > Avoid stack overflow in the presence of cycles in controller inclusion > -- > > Key: OFBIZ-11314 > URL: https://issues.apache.org/jira/browse/OFBIZ-11314 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: 0001-Improved-Rewrite-Digraph.patch, > 0001-Improved-Rewrite-Digraph.patch, > 0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch > > > The inclusion of controller configuration files can lead to inclusion cycles > which are not safely handled, because they can lead to infinite recursion > that end up in stack overflow exception. > A very basic form of cycle is controllers A and B which includes each other. > I would be better to check the inclusion cycles and report an appropriate > error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006892#comment-17006892 ] Mathieu Lirzin commented on OFBIZ-10577: Hello [~ankit.joshi], I am not sure to understand what an "inventory cycle count" mean. Can you expand on it? Maybe that was already planned, but I recommend opening a discussion on d...@ofbiz.apache.org to allow other contributors to discuss the modelisation of that domain. > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId > statusId > createdDatetime > *InventoryCountItem* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > itemStatusId > locationSeqId > productId > productIdentifier > quantity > *InventoryCountVariance* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > productId > productIdentifier > locationSeqId > systemQuantityOnHand > actualQuantityOnHand > varianceQuantityOnHand > totalCost > actualCost > costVariance > actualValue > totalValue > valueVariance > unitCost > *ProductCategoryFacilityLocation* > facilityId > locationSeqId > productCategoryId > fromDate > thruDate > isCountable > *Extended entity:* > *FacilityLocation* > locked > lastCountDate > nextCountDate > *ProductCategory* > isCountable > We will prevent following inbound and outbound transactions within the > application if the location is locked for counting: > Inventory Transfer >
[jira] [Updated] (OFBIZ-11314) Avoid stack overflow in the presence of cycles in controller inclusion
[ https://issues.apache.org/jira/browse/OFBIZ-11314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11314: --- Description: The inclusion of controller configuration files can lead to inclusion cycles which are not safely handled, because they can lead to infinite recursion that end up in stack overflow exception. A very basic form of cycle is controllers A and B which includes each other. I would be better to check the inclusion cycles and report an appropriate error. was: The inclusion of controller configuration files can lead to inclusion cycles which are not safely handled, because they can lead to infinite recursion that end up in stack overflow exception. A very basic form of cycle is controllers A and B which includes each other. I would be better to checket the inclusion cycles and report an appropriate error. > Avoid stack overflow in the presence of cycles in controller inclusion > -- > > Key: OFBIZ-11314 > URL: https://issues.apache.org/jira/browse/OFBIZ-11314 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: 0001-Improved-Rewrite-Digraph.patch, > 0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch > > > The inclusion of controller configuration files can lead to inclusion cycles > which are not safely handled, because they can lead to infinite recursion > that end up in stack overflow exception. > A very basic form of cycle is controllers A and B which includes each other. > I would be better to check the inclusion cycles and report an appropriate > error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11314) Avoid stack overflow in the presence of cycles in controller inclusion
[
https://issues.apache.org/jira/browse/OFBIZ-11314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006881#comment-17006881
]
Mathieu Lirzin commented on OFBIZ-11314:
I will commit [^0001-Improved-Rewrite-Digraph.patch] and
[^0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch] in 3 days
if nobody objects.
Those patches are meant to be applied in order and must be applied using {{git
am XXX.patch}}.
> Avoid stack overflow in the presence of cycles in controller inclusion
> --
>
> Key: OFBIZ-11314
> URL: https://issues.apache.org/jira/browse/OFBIZ-11314
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Improved-Rewrite-Digraph.patch,
> 0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch
>
>
> The inclusion of controller configuration files can lead to inclusion cycles
> which are not safely handled, because they can lead to infinite recursion
> that end up in stack overflow exception.
> A very basic form of cycle is controllers A and B which includes each other.
> I would be better to checket the inclusion cycles and report an appropriate
> error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11314) Avoid stack overflow in the presence of cycles in controller inclusion
[ https://issues.apache.org/jira/browse/OFBIZ-11314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11314: --- Attachment: 0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch 0001-Improved-Rewrite-Digraph.patch > Avoid stack overflow in the presence of cycles in controller inclusion > -- > > Key: OFBIZ-11314 > URL: https://issues.apache.org/jira/browse/OFBIZ-11314 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: 0001-Improved-Rewrite-Digraph.patch, > 0002-Improved-Detect-inclusion-cycles-in-controller-confi.patch > > > The inclusion of controller configuration files can lead to inclusion cycles > which are not safely handled, because they can lead to infinite recursion > that end up in stack overflow exception. > A very basic form of cycle is controllers A and B which includes each other. > I would be better to checket the inclusion cycles and report an appropriate > error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11314) Avoid stack overflow in the presence of cycles in controller inclusion
Mathieu Lirzin created OFBIZ-11314: -- Summary: Avoid stack overflow in the presence of cycles in controller inclusion Key: OFBIZ-11314 URL: https://issues.apache.org/jira/browse/OFBIZ-11314 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin The inclusion of controller configuration files can lead to inclusion cycles which are not safely handled, because they can lead to infinite recursion that end up in stack overflow exception. A very basic form of cycle is controllers A and B which includes each other. I would be better to checket the inclusion cycles and report an appropriate error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (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 closed OFBIZ-11313.
--
Fix Version/s: Upcoming Branch
Resolution: Implemented
Thanks [~jamesyong] for the review.
> Parsing included controller files eagerly
> -
>
> Key: OFBIZ-11313
> URL: https://issues.apache.org/jira/browse/OFBIZ-11313
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> 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:
---
Issue Type: Improvement (was: Bug)
> Parsing included controller files eagerly
> -
>
> Key: OFBIZ-11313
> URL: https://issues.apache.org/jira/browse/OFBIZ-11313
> Project: OFBiz
> Issue Type: Improvement
> 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] [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
[jira] [Commented] (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 commented on OFBIZ-11007:
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 URI
> resolution nor with _overrideView()_ feature.
> Combined with work on associating URIs and HTTP methods done by [~mthl] in
> OFBIZ-10438 , we are now able to provide RESTful APIs as follows:
> {code:java}
>
> ...
>
> ...
>
> ...
> {code}
> After we matched a request-map having parametrized URI as in
> {code:java}
> uri="foo/bar/{baz}"
> {code}
> the value is available inside the request attributes with the corresponding
> key (here _"baz"_)
> The *restful_URIs.patch* allows segmented URI support.
> The *entitymaint_example.patch* is a modified _entitymaint_ part that serves
> as an example of possible application of new system.
> Any questions or comments are welcomed.
--
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/29/19 2:58 PM:
--
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 URI
>
[jira] [Commented] (OFBIZ-11311) Themes documentation migration from md to asciidoc
[ https://issues.apache.org/jira/browse/OFBIZ-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000895#comment-17000895 ] Mathieu Lirzin commented on OFBIZ-11311: I find that this is a great idea to homogenize the documentation format and location. I am not a fan of the current practice of spreading included documentation files into components directories but that's another topic so +1 If you are willing to continue to work on that a nice next step would be to migrate the $COMPONENT/documents/*.xml files into asciidoc. > Themes documentation migration from md to asciidoc > -- > > Key: OFBIZ-11311 > URL: https://issues.apache.org/jira/browse/OFBIZ-11311 > Project: OFBiz > Issue Type: Improvement > Components: themes >Affects Versions: Trunk >Reporter: Olivier Heintz >Priority: Minor > Attachments: OFBIZ-11311.patch, themes.adoc > > > Include Themes documentation in developper-manual, so > * I have migrates README.md from themes directory to themes.adoc > * add a include line in developper-manual > > As this documentation is about themes (a directory in ofbiz root) I have'nt > created a doc/documentation directory in the themes directory but only put > file at the same place than the previous README.md -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11296. -- Resolution: Later > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin reassigned OFBIZ-11296: -- Assignee: (was: Mathieu Lirzin) > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996428#comment-16996428
]
Mathieu Lirzin commented on OFBIZ-6993:
---
Hello Jacques, the fix is not backported on 17.12 and 18.12 yet, I was waiting
some time to let people report potential issues introduced by the fix added on
trunk. Since nobody has complain, I think we can proceed with the backport.
I don't have much time to devote to that backport task, [~jleroux] are you
available to work on that? (the plugins repository needs to be updated too)
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Forrest Rae
>Assignee: Mathieu Lirzin
>Priority: Major
> Fix For: Release Branch 17.12, Release Branch 18.12
>
> Attachments:
> 0001-Fixed-when-it-comes-to-web.xml-we-should-rely-solely.patch, web-app.patch
>
>
> Been seeing the error below in the logs. Strangely, I've not been able to
> catch the exception in a debugger, but was able to isolate it to the
> definition of the web-app with version 3.0. The error disapears when you
> change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at
[jira] [Commented] (OFBIZ-11296) Use 'depends-on' everywhere
[
https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990833#comment-16990833
]
Mathieu Lirzin commented on OFBIZ-11296:
Hello [~mbrohl]
To my knowledge
[^OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch]
has not much impact because the {{component-load.xml}} feature is still
available for productive installations in case they want to activate/reorder
components using this feature (they simply need to create a file in the
directory of their choice). Did you notice a bug?
>From my point of view the change did not require a prior discussion, but I
>might be overlooking some important aspect that make it necessary to have such
>discussion. Maybe you have something specific in mind ?
> Use 'depends-on' everywhere
> ---
>
> Key: OFBIZ-11296
> URL: https://issues.apache.org/jira/browse/OFBIZ-11296
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments:
> OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch
>
>
> We currently have two ways to define component loading order. Either
> by using ‘depends-on’ attribute in “component-config.xml” or by adding
> a “component-load.xml” file at the root of a component directory.
> “depends-on” is more flexible because it handles partial ordering when
> “component-load.xml” defines a total order which is not necessarily
> meaningful, so it is better to rely only “depends-on”.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990824#comment-16990824
]
Mathieu Lirzin commented on OFBIZ-6993:
---
{quote}
So you finally prefer to put the Jira issue number on the title line?
{quote}
Sorry that was simply a mistake (For the record my personnal preference remains
to include the ticket reference in the body).
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
>
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990635#comment-16990635
]
Mathieu Lirzin commented on OFBIZ-6993:
---
Hopefully after both updating trunk from framework and plugins no more warnings
should show up.
I will wait a few to ensure that I did not overlook anything before backporting
on release branches.
Thanks [~stregouet]
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
>
[jira] [Closed] (OFBIZ-11019) Cleaning the bloated ‘Security’ interface
[
https://issues.apache.org/jira/browse/OFBIZ-11019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin closed OFBIZ-11019.
--
Resolution: Later
I think a more global approach should be taken on the rewrite of the
{{Security}} interface, as a consequence I withdraw my patch proposal.
> Cleaning the bloated ‘Security’ interface
> -
>
> Key: OFBIZ-11019
> URL: https://issues.apache.org/jira/browse/OFBIZ-11019
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments:
> OFBIZ-11019_Relax-the-contract-of-the-Security-interfac.patch
>
>
> The ‘hasPermission(String, HttpSession)’ method declaration from the
> ‘Security’ interface is breaking the minimality principle of interfaces
> because it is easily expressible in term of ‘hasPermission(String,
> GenericEntity)’. As a consequence a static helper method should be
> implemented to achieve same convenience without polluting the ‘Security’
> interface.
> Other methods in that interface are suffering from the same issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-10805) OFBiz shell
[
https://issues.apache.org/jira/browse/OFBIZ-10805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin closed OFBIZ-10805.
--
Fix Version/s: (was: Upcoming Branch)
Resolution: Abandoned
I am not interested to work on that feature given that OFBiz does not provide a
proper API for managing its resources yet. OFBiz needs to become a library to
allow such feature to integrate nicely.
> OFBiz shell
> ---
>
> Key: OFBIZ-10805
> URL: https://issues.apache.org/jira/browse/OFBIZ-10805
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Major
> Attachments: OFBIZ-10805_OFBiz-shell.patch
>
>
> One issue with the current way of writing Groovy tests is that the feedback
> between writing an instruction and checking its result is slow because one
> has to rerun the corresponding test case.
> Providing a Groovy shell access with a delegator and dispatcher allows
> developers to interactively execute commands and check their results
> instantly.
> The shell access has been done via Remote Procedure Call (RPC) which was
> already implemented by the {{AdminClient}} and {{AdminServer}} classes.
> In order to test, you must start the server first:
> {code}
> $ ./gradlew ofbiz
> {code}
> then you can run the following command in another terminal:
> {code}
> $ java -jar build/libs/ofbiz.jar --shell
> {code}
> or this equivalent one which uses the corresponding short option:
> {code}
> $ java -jar build/libs/ofbiz.jar -i
> {code}
> *Limitation*: It is currently not possible to connect multiple shells at
> the same time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OFBIZ-10966) JSON entity data import and export utility
[
https://issues.apache.org/jira/browse/OFBIZ-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin reassigned OFBIZ-10966:
--
Assignee: Jayansh Shinde (was: Mathieu Lirzin)
Hello [~jayansh], Are there any news regarding the cause of the failing tests?
> JSON entity data import and export utility
> --
>
> Key: OFBIZ-10966
> URL: https://issues.apache.org/jira/browse/OFBIZ-10966
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Jayansh Shinde
>Assignee: Jayansh Shinde
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10966_27062019.patch, OFBiz-10966.patch,
> OFBiz-Web-Tools-JSON-Data-Export-All.png,
> OFBiz-Web-Tools-JSON-Data-Import-Dir.png, exportJson.png, importJson.png
>
>
> Currently, we support import/export entity data in XML format.
> Nowadays JSON is widely used in industry, we can have support for JSON
> format which looks quite similar to XML support.
> Here is example of XML data and it's JSON version
> {code:java}
>
> {code}
> {code:java}
> {“Party”:
> {"partyId":"123456","partyTypeId":"PERSON","statusId":"PARTY_ENABLED”}}
> {code}
>
> *Design Proposal*
> We can write *entityImportJson* and *entityImportDirJson* services for
> importing JSON from screen and directory respectively.
> And the *entityExportAllJson* service for exporting entity data in JSON.
>
> *Import Design*
> The import service will perform following operations:
> 1.) Validate the input JSON data (I am in process of exploring the way for
> this)
> 2.) On successful validation, convert JSON to OFBiz's entity model
> (GenericValue)
> 3.) The GenericValue will be inserted in database by some handler class for
> e.g we can write JsonDataHandler, it will convert given JSON to
> List, and finally write it to database (Similar pattern is used
> in XML import).
>
> *Export Design*
> Based on existing XML pattern the writeXmlText method of GenericEntity class
> write the exported data in XML format.
> In the similar way, we can implement writeJsonText to export data in JSON
> format.
> Please free feel to share your thought.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11304) Install a Checkstyle pre-commit on every committer machine
[
https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990515#comment-16990515
]
Mathieu Lirzin commented on OFBIZ-11304:
Hello [~jleroux],
I like the idea of automating the execution of {{gradlew check}}. However since
this is not a cheap operation (it makes my 8 core CPU heat and pur) it might be
a bit too much to run it before each commit. Maybe we could delay the execution
to the [pre push|https://www.git-scm.com/docs/githooks#_pre_push] phase or
later.
What do you think?
> Install a Checkstyle pre-commit on every committer machine
> --
>
> Key: OFBIZ-11304
> URL: https://issues.apache.org/jira/browse/OFBIZ-11304
> Project: OFBiz
> Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
>
> The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by
> the check gradle task. It's "hard" to exactly know from where lint errors
> come among all still present.
> I think we should rely on a Checkstyle pre-commit hook like
> https://gist.github.com/davetron5000/37350 to complement
> tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when
> a lint error is present in the commit.
> Every committer would have it installed locally and the problem would be gone
> with some committers good will. I started a discussion about it at
> https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same
> proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11007) REST: adding segmented URI support
[
https://issues.apache.org/jira/browse/OFBIZ-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990467#comment-16990467
]
Mathieu Lirzin commented on OFBIZ-11007:
[~nmalin] Can you take a look at [^entitymaint_example.patch] to fix the issue
reported by [~jleroux]? Feel free to assign the ticket to yourself If you want
to do the work.
> 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: Mathieu Lirzin
>Priority: Minor
> Labels: REST, URI
> Fix For: Upcoming Branch
>
> Attachments: 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 URI
> resolution nor with _overrideView()_ feature.
> Combined with work on associating URIs and HTTP methods done by [~mthl] in
> OFBIZ-10438 , we are now able to provide RESTful APIs as follows:
> {code:java}
>
> ...
>
> ...
>
> ...
> {code}
> After we matched a request-map having parametrized URI as in
> {code:java}
> uri="foo/bar/{baz}"
> {code}
> the value is available inside the request attributes with the corresponding
> key (here _"baz"_)
> The *restful_URIs.patch* allows segmented URI support.
> The *entitymaint_example.patch* is a modified _entitymaint_ part that serves
> as an example of possible application of new system.
> Any questions or comments are welcomed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11302) Remove redundant ofbizDebug task type
[ https://issues.apache.org/jira/browse/OFBIZ-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985990#comment-16985990 ] Mathieu Lirzin commented on OFBIZ-11302: Indeed [~jleroux], a discussion on the mailing list might be a good idea. Feel free to send an email in that direction, I will revert if necessary. Unless I am mistaken the behavior is strictly equivalent. > Remove redundant ofbizDebug task type > - > > Key: OFBIZ-11302 > URL: https://issues.apache.org/jira/browse/OFBIZ-11302 > Project: OFBiz > Issue Type: Improvement > Components: Gradle >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11303) Reference to obsolete workflow component
[ https://issues.apache.org/jira/browse/OFBIZ-11303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11303. -- Resolution: Fixed > Reference to obsolete workflow component > > > Key: OFBIZ-11303 > URL: https://issues.apache.org/jira/browse/OFBIZ-11303 > Project: OFBiz > Issue Type: Bug >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11302) Remove redundant ofbizDebug task type
[ https://issues.apache.org/jira/browse/OFBIZ-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11302. -- Resolution: Resolved > Remove redundant ofbizDebug task type > - > > Key: OFBIZ-11302 > URL: https://issues.apache.org/jira/browse/OFBIZ-11302 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11303) Reference to obsolete workflow component
Mathieu Lirzin created OFBIZ-11303: -- Summary: Reference to obsolete workflow component Key: OFBIZ-11303 URL: https://issues.apache.org/jira/browse/OFBIZ-11303 Project: OFBiz Issue Type: Bug Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin Fix For: Upcoming Branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11302) Remove redundant ofbizDebug task type
Mathieu Lirzin created OFBIZ-11302: -- Summary: Remove redundant ofbizDebug task type Key: OFBIZ-11302 URL: https://issues.apache.org/jira/browse/OFBIZ-11302 Project: OFBiz Issue Type: Improvement Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin Fix For: Upcoming Branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11281) Possible Nullpointer in StringUtil#strToMap
[
https://issues.apache.org/jira/browse/OFBIZ-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985636#comment-16985636
]
Mathieu Lirzin commented on OFBIZ-11281:
[~uHeidfeld] Thanks for your answer, Indeed for dates there is no notion of
emptiness like in collections, the Optional class can model the emptiness
for such kind of types in a type safe manner. IMO there is no need to worry
about allocating empty collections (The JVM is very powerful and such
allocation is most case negligeable).
After some investigation it appears that strToMap is only used in the framework
in
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/valuelink/ValueLinkApi.java
for doing ad-hoc parsing (meaning not good ;-)) that will eventually be
reimplemented which would lead to strToMap deprecation/removal, as a
consequence I think you should consider using your own implementation of map
parsing to replace strToMap in your code.
[~nmalin] As I understand it, {{StringUtil}} is mostly legacy stuff that will
be deprecated/removed sooner or later so I am not sure adding more flexibility
is desirable in this context, it would be better to work on getting rid of
remaining legacy code and in the case of ‘strToXXX‘ use standard serialisation
formats like JSON, XML, CSV or other alternatives but backed with a serious
parser. :-)
> Possible Nullpointer in StringUtil#strToMap
> ---
>
> Key: OFBIZ-11281
> URL: https://issues.apache.org/jira/browse/OFBIZ-11281
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Ulrich Heidfeld
>Assignee: Nicolas Malin
>Priority: Critical
> Fix For: 17.12.01, Upcoming Branch, 18.12.01
>
> Attachments:
> OFBIZ-11281_Possible_Nullpointer_in_StringUtil#strToMap.patch
>
>
> StringUtil#strToMap(String, String, boolean, String) throws Nullpointer for
> StringUtil.strToMap("", false).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11301) Clarify usage of Github PR
[ https://issues.apache.org/jira/browse/OFBIZ-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984879#comment-16984879 ] Mathieu Lirzin commented on OFBIZ-11301: Personnally I think the CONTRIBUTING.adoc file I proposed in OFBIZ-11271 (but did not implement yet) might be a better fit for such information than README.adoc > Clarify usage of Github PR > -- > > Key: OFBIZ-11301 > URL: https://issues.apache.org/jira/browse/OFBIZ-11301 > Project: OFBiz > Issue Type: Sub-task > Components: git >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > > I started a discussion at https://markmail.org/message/jx426hxxwvllynx3, > summary: > Our workflow is to contribute patches through Jira. I want to clearly > document that in > https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices > But I know that it will not be enough. The PR reflex is now an acquired > behaviour. So I'll also add a notice in the top of our main README.adoc to > make it clear on our main Github page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983921#comment-16983921
]
Mathieu Lirzin commented on OFBIZ-6993:
---
Hello [~jleroux], I get the same error on my machine. I was tired and didn't
check the actual behavior before committing, sorry for the confusion.
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at
[jira] [Reopened] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin reopened OFBIZ-6993:
---
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at
[jira] [Closed] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin closed OFBIZ-6993.
-
Fix Version/s: Release Branch 18.12
Release Branch 17.12
Upcoming Branch
Resolution: Fixed
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at
[jira] [Assigned] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin reassigned OFBIZ-6993:
-
Assignee: Mathieu Lirzin
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at
[jira] [Closed] (OFBIZ-11300) Integration of Tomcat in the build system
[ https://issues.apache.org/jira/browse/OFBIZ-11300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11300. -- Resolution: Implemented > Integration of Tomcat in the build system > - > > Key: OFBIZ-11300 > URL: https://issues.apache.org/jira/browse/OFBIZ-11300 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11300) Integration of Tomcat in the build system
Mathieu Lirzin created OFBIZ-11300: -- Summary: Integration of Tomcat in the build system Key: OFBIZ-11300 URL: https://issues.apache.org/jira/browse/OFBIZ-11300 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin Fix For: Upcoming Branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11161) OFBiz distribution should not require including extra content
[
https://issues.apache.org/jira/browse/OFBIZ-11161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11161:
---
Attachment:
OFBIZ-11161_0005-Do-not-exclude-files-from-component-config-.patch
> OFBiz distribution should not require including extra content
> -
>
> Key: OFBIZ-11161
> URL: https://issues.apache.org/jira/browse/OFBIZ-11161
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Major
> Attachments:
> OFBIZ-11161_0001-Separate-resources-from-Java-source-files.patch,
> OFBIZ-11161_0002-Don-t-exclude-properties-and-labels-file-fr.patch,
> OFBIZ-11161_0003-framework_Remove-redundant-dtd-directory-from-classpa.patch,
> OFBIZ-11161_0003-plugins_Remove-redundant-dtd-directory-from-classpa.patch,
> OFBIZ-11161_0004-Move-APACHE2_HEADER_FOR_XML.patch,
> OFBIZ-11161_0005-Do-not-exclude-files-from-component-config-.patch
>
>
> Currently to deploy OFBiz it is necessary to include the source directories
> containing xml and groovy files in addition of {{ofbiz.jar}}, because loading
> of those files is not done using the standard [location independent resource
> mechanism|https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html]
> of Java.
> To facilitate the deployment on production servers, the following
> configuration is added in {{build.gradle}}
> {code:groovy}
> distributions.main.contents.from(rootDir) {
> include 'framework/**', 'applications/**', 'themes/**', 'plugins/**'
> }
> {code}
> However this doesn't solve the problem that OFBiz is not usable as a library
> downloaded from a Jar repository. The proper solution would be to remove any
> dependencies on OFBiz home directory and bundle every resource in
> {{ofbiz.jar}}
> This has been [discussed on Development mailing
> list|https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126@%3Cdev.ofbiz.apache.org%3E]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11296. -- Resolution: Resolved Commited in eeabe69813a1d9f42911dec70a912574046ef49b > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11296) Use 'depends-on' everywhere
[ https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11296: --- Attachment: OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch > Use 'depends-on' everywhere > --- > > Key: OFBIZ-11296 > URL: https://issues.apache.org/jira/browse/OFBIZ-11296 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch > > > We currently have two ways to define component loading order. Either > by using ‘depends-on’ attribute in “component-config.xml” or by adding > a “component-load.xml” file at the root of a component directory. > “depends-on” is more flexible because it handles partial ordering when > “component-load.xml” defines a total order which is not necessarily > meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11275:
---
Fix Version/s: (was: Trunk)
Upcoming Branch
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk, 18.12.01
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch,
> 0004-Fixed-graphSpec-should-be-a-LinkedHashMap-to-preserv.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OFBIZ-11296) Use 'depends-on' everywhere
Mathieu Lirzin created OFBIZ-11296: -- Summary: Use 'depends-on' everywhere Key: OFBIZ-11296 URL: https://issues.apache.org/jira/browse/OFBIZ-11296 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin Fix For: Upcoming Branch We currently have two ways to define component loading order. Either by using ‘depends-on’ attribute in “component-config.xml” or by adding a “component-load.xml” file at the root of a component directory. “depends-on” is more flexible because it handles partial ordering when “component-load.xml” defines a total order which is not necessarily meaningful, so it is better to rely only “depends-on”. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin closed OFBIZ-11275.
--
Resolution: Fixed
Applied with an extra XXX comment to describe why we need a linkedhashmap.
Thanks [~stregouet] for the fix.
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk, 18.12.01
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Fix For: Trunk
>
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch,
> 0004-Fixed-graphSpec-should-be-a-LinkedHashMap-to-preserv.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11281) Possible Nullpointer in StringUtil#strToMap
[
https://issues.apache.org/jira/browse/OFBIZ-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974144#comment-16974144
]
Mathieu Lirzin commented on OFBIZ-11281:
Hello,
First thanks providing a test case.
I think there is a confusion because "possible NPE" is not a bug per say, but
"having an NPE at runtime" is.
To explain the important distinction let me give you an example more
meaningful. Imagine some method signature {{Double divide(int x, int y)}}
which calculates the result of x/y. Should we consider "Possible
{{DivisionByZero}} exception" is a bug ? *No*. Additionally Would it makes
sense to return {{null}} when y = 0 ? *Probably not*.
So in general to fix a "NPE happening at runtime" bug, this can be done by
either by:
- specifying that the method *must not* be called with certain values that are
outside its domain ({{null}}, "" or whatever) and fix the caller.
- specifying explicitly that {{null}} value is part of the domain of the method
and adapt the implementation accordingly
Regarding [^OFBIZ-11281_Possible_Nullpointer_in_StringUtil#strToMap.patch] I
would like to know why it would be desirable to consider the empty string part
of the domain of {{strToMap}} and if there is a reason why {{null}} is returned
instead of {{Collections.emptyMap}}?
> Possible Nullpointer in StringUtil#strToMap
> ---
>
> Key: OFBIZ-11281
> URL: https://issues.apache.org/jira/browse/OFBIZ-11281
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Ulrich Heidfeld
>Assignee: Nicolas Malin
>Priority: Critical
> Fix For: 17.12.01, Upcoming Branch, 18.12.01
>
> Attachments:
> OFBIZ-11281_Possible_Nullpointer_in_StringUtil#strToMap.patch
>
>
> StringUtil#strToMap(String, String, boolean, String) throws Nullpointer for
> StringUtil.strToMap("", false).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin reopened OFBIZ-11275:
Here is the error I got when doing {{gradlew cleanAll loadAll}} after applying
[^0003-Fixed-Remove-dependency-management-from-ComponentCon.patch] I am
reverting the corresponding commit
{code}
2019-11-09 00:47:42,695 |main |EntityDataLoadContainer
|I| =-=-=-=-=-=-= Starting the data load...
2019-11-09 00:47:42,698 |main |EntitySaxReader
|I| Beginning import from URL:
file:/home/mthl/src/ofbiz/framework/entityext/data/EntityExtTypeData.xml
2019-11-09 00:47:42,705 |main |EntitySaxReader
|I| Transaction Timeout set to 2 hours (7200 seconds)
2019-11-09 00:47:42,755 |main |EntitySaxReader
|I| Finished 12 values from
file:/home/mthl/src/ofbiz/framework/entityext/data/EntityExtTypeData.xml
2019-11-09 00:47:42,755 |main |EntitySaxReader
|I| Beginning import from URL:
file:/home/mthl/src/ofbiz/framework/entityext/data/EntityExtSecurityPermissionSeedData.xml
2019-11-09 00:47:42,757 |main |EntitySaxReader
|I| Transaction Timeout set to 2 hours (7200 seconds)
2019-11-09 00:47:42,775 |main |TransactionUtil
|W| Calling transaction setRollbackOnly; this stack trace shows where this is
happening:
java.lang.Exception: rollback called in Entity Engine SQLProcessor
at
org.apache.ofbiz.entity.transaction.TransactionUtil.setRollbackOnly(TransactionUtil.java:358)
[main/:?]
at
org.apache.ofbiz.entity.jdbc.SQLProcessor.rollback(SQLProcessor.java:185)
[main/:?]
at
org.apache.ofbiz.entity.datasource.GenericDAO.insert(GenericDAO.java:112)
[main/:?]
at
org.apache.ofbiz.entity.datasource.GenericHelperDAO.create(GenericHelperDAO.java:67)
[main/:?]
at
org.apache.ofbiz.entity.GenericDelegator.create(GenericDelegator.java:855)
[main/:?]
at
org.apache.ofbiz.entity.GenericDelegator.storeAll(GenericDelegator.java:1304)
[main/:?]
at
org.apache.ofbiz.entity.util.EntitySaxReader.writeValues(EntitySaxReader.java:258)
[main/:?]
at
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:228)
[main/:?]
at
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:205)
[main/:?]
at
org.apache.ofbiz.entity.util.EntityDataLoader.loadData(EntityDataLoader.java:268)
[main/:?]
at
org.apache.ofbiz.entityext.data.EntityDataLoadContainer.loadData(EntityDataLoadContainer.java:433)
[main/:?]
at
org.apache.ofbiz.entityext.data.EntityDataLoadContainer.loadDataForDelegator(EntityDataLoadContainer.java:184)
[main/:?]
at
org.apache.ofbiz.entityext.data.EntityDataLoadContainer.init(EntityDataLoadContainer.java:115)
[main/:?]
at
org.apache.ofbiz.base.container.ContainerLoader.loadContainer(ContainerLoader.java:143)
[main/:?]
at
org.apache.ofbiz.base.container.ContainerLoader.loadContainersFromConfigurations(ContainerLoader.java:107)
[main/:?]
at
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:75)
[main/:?]
at
org.apache.ofbiz.base.start.StartupControlPanel.loadContainers(StartupControlPanel.java:160)
[main/:?]
at
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:71)
[main/:?]
at org.apache.ofbiz.base.start.Start.main(Start.java:90) [main/:?]
2019-11-09 00:47:42,782 |main |GenericDelegator
|E| Failure in create operation for entity [SecurityGroupPermission]:
org.apache.ofbiz.entity.GenericEntityException: Error while inserting:
[GenericEntity:SecurityGroupPermission][createdStamp,2019-11-09
00:47:42.768(java.sql.Timestamp)][createdTxStamp,2019-11-09
00:47:42.757(java.sql.Timestamp)][fromDate,2001-05-13
12:00:00.0(java.sql.Timestamp)][groupId,SUPER(java.lang.String)][lastUpdatedStamp,2019-11-09
00:47:42.768(java.sql.Timestamp)][lastUpdatedTxStamp,2019-11-09
00:47:42.757(java.sql.Timestamp)][permissionId,ENTITY_SYNC_ADMIN(java.lang.String)]
(SQL Exception while executing the following:INSERT INTO
OFBIZ.SECURITY_GROUP_PERMISSION (GROUP_ID, PERMISSION_ID, FROM_DATE, THRU_DATE,
LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP)
VALUES (?, ?, ?, ?, ?, ?, ?, ?) (INSERT on table 'SECURITY_GROUP_PERMISSION'
caused a violation of foreign key constraint 'SEC_GRP_PERM_GRP' for key
(SUPER). The statement has been rolled back.)). Rolling back transaction.
2019-11-09 00:47:42,782 |main |TransactionUtil
|I| Transaction rollback only not set, rollback only is already set.
2019-11-09 00:47:42,782 |main |GenericDelegator
|E| Failure in storeAll operation:
[jira] [Commented] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970452#comment-16970452
]
Mathieu Lirzin commented on OFBIZ-11275:
Thanks for your contribution [~stregouet]
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk, 18.12.01
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Fix For: Trunk
>
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin closed OFBIZ-11275.
--
Fix Version/s: Trunk
Resolution: Fixed
Fix in commits 1317703c9a, 7044af8a6f and 3d3533cf5e.
Those commits has not been backported in 18.12 where the bug is present because
since many things have changed between 18.12 and trunk in
{{ComponentContainer}}. If someone is motivated by investing some time in the
backport work. Feel free to reopen the ticket.
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk, 18.12.01
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Fix For: Trunk
>
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11275:
---
Component/s: framework
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk, 18.12.01
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11275:
---
Affects Version/s: 18.12.01
Trunk
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Trunk, 18.12.01
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11274) Cannot set property 'value' of null in lookup.js set_multivalues() function
[
https://issues.apache.org/jira/browse/OFBIZ-11274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968566#comment-16968566
]
Mathieu Lirzin commented on OFBIZ-11274:
Additonally I have noticed that
{{./themes/common-theme/template/includes/Lookup.ftl}} contains a copy of the
{{set_multivalues()}} method. What should we do about it?
> Cannot set property 'value' of null in lookup.js set_multivalues() function
> ---
>
> Key: OFBIZ-11274
> URL: https://issues.apache.org/jira/browse/OFBIZ-11274
> Project: OFBiz
> Issue Type: Bug
> Components: themes
>Affects Versions: Trunk
>Reporter: Daniel Watford
>Priority: Major
> Labels: pull-request-available
> Attachments: OFBIZ-11274-lookup-set-multi.patch
>
>
> Attempts to call lookup.js function set_multivalues() from a lookup screen
> fail with the console logging error:
> {noformat}
> Uncaught TypeError: Cannot set property 'value' of null
> at set_multivalues (fieldlookup.js:769)
> at :1:1{noformat}
> No framework or plugins appear to currently use this function.
> The set_multivalues() function should be useful for populating multiple
> fields (e.g. a Postal Address) on a form from a lookup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OFBIZ-11275) bug in depends-on in ofbiz-component.xml
[
https://issues.apache.org/jira/browse/OFBIZ-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin reassigned OFBIZ-11275:
--
Assignee: Mathieu Lirzin
> bug in depends-on in ofbiz-component.xml
>
>
> Key: OFBIZ-11275
> URL: https://issues.apache.org/jira/browse/OFBIZ-11275
> Project: OFBiz
> Issue Type: Bug
>Reporter: Samuel Trégouët
>Assignee: Mathieu Lirzin
>Priority: Major
> Attachments:
> 0001-Implemented-Show-dependency-resolution-algorithm-pro.patch,
> 0002-Implemented-Add-a-generic-directed-graph-utilitary-c.patch,
> 0003-Fixed-Remove-dependency-management-from-ComponentCon.patch
>
>
> when using `depends-on` tag in obfiz-component.xml one should expect ofbiz to
> load component (and in particular container listed in ofbiz-component.xml) in
> particular order.
> I mean if component `accounting` has this line in its ofbiz-component.xml
> {noformat}
> {noformat}
> ofbiz should load order component first and then accounting. This is not the
> case. Only classpath is modified according to depends-on declaration (and
> this is not really a usefull/used feature but we'll see this in another issue
> ;) )
> So here are patches to fix this issue. First one is only a test (which is
> skipped to allow ./gradlew test to be ok, so if one need to be convinced one
> should comment Ignore annotation) to illustrate issue, the two others are
> actual fixes
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11274) Cannot set property 'value' of null in lookup.js set_multivalues() function
[
https://issues.apache.org/jira/browse/OFBIZ-11274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968563#comment-16968563
]
Mathieu Lirzin commented on OFBIZ-11274:
Hello Daniel,
The fact that this not used anywhere in the framework or plugins makes me think
that maybe we don't need it. In order to demonstrate the value of this code it
would be nice if you could make the framework use it in some appropriate place.
This would help reviewing the code too. Are you willing to do that? :-)
Thanks
> Cannot set property 'value' of null in lookup.js set_multivalues() function
> ---
>
> Key: OFBIZ-11274
> URL: https://issues.apache.org/jira/browse/OFBIZ-11274
> Project: OFBiz
> Issue Type: Bug
> Components: themes
>Affects Versions: Trunk
>Reporter: Daniel Watford
>Priority: Major
> Labels: pull-request-available
> Attachments: OFBIZ-11274-lookup-set-multi.patch
>
>
> Attempts to call lookup.js function set_multivalues() from a lookup screen
> fail with the console logging error:
> {noformat}
> Uncaught TypeError: Cannot set property 'value' of null
> at set_multivalues (fieldlookup.js:769)
> at :1:1{noformat}
> No framework or plugins appear to currently use this function.
> The set_multivalues() function should be useful for populating multiple
> fields (e.g. a Postal Address) on a form from a lookup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OFBIZ-11271) Add a ‘CONTRIBUTING.adoc’ file
Mathieu Lirzin created OFBIZ-11271:
--
Summary: Add a ‘CONTRIBUTING.adoc’ file
Key: OFBIZ-11271
URL: https://issues.apache.org/jira/browse/OFBIZ-11271
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Mathieu Lirzin
Assignee: Mathieu Lirzin
Contributing guidelines are currently defined in
[Confluence|https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contribution+and+Development]
which is far from the code and not easily editable locally. It would be better
to have a {{CONTRIBUTING.adoc}} file inside the framework repository.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11260) remove ServiceEventHandler.checkSecureParameter
[ https://issues.apache.org/jira/browse/OFBIZ-11260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11260: --- Affects Version/s: Trunk > remove ServiceEventHandler.checkSecureParameter > --- > > Key: OFBIZ-11260 > URL: https://issues.apache.org/jira/browse/OFBIZ-11260 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Samuel Trégouët >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: 01-lint.patch, 02-remove-checkSecureParameter.patch > > > As discussed on d...@ofbiz.apache.org [1] I see no reason to keep this > function, so I suggest to remove it (patch attached with some checkstyle > linting recommendatione applied) > > > [1] > https://lists.apache.org/thread.html/a59689954e2ef5ad8289bfda70bc54ad795dcff6bd12d5aa11755ca4@%3Cdev.ofbiz.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11260) remove ServiceEventHandler.checkSecureParameter
[ https://issues.apache.org/jira/browse/OFBIZ-11260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11260: --- Issue Type: Improvement (was: Bug) > remove ServiceEventHandler.checkSecureParameter > --- > > Key: OFBIZ-11260 > URL: https://issues.apache.org/jira/browse/OFBIZ-11260 > Project: OFBiz > Issue Type: Improvement >Reporter: Samuel Trégouët >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: 01-lint.patch, 02-remove-checkSecureParameter.patch > > > As discussed on d...@ofbiz.apache.org [1] I see no reason to keep this > function, so I suggest to remove it (patch attached with some checkstyle > linting recommendatione applied) > > > [1] > https://lists.apache.org/thread.html/a59689954e2ef5ad8289bfda70bc54ad795dcff6bd12d5aa11755ca4@%3Cdev.ofbiz.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11260) remove ServiceEventHandler.checkSecureParameter
[ https://issues.apache.org/jira/browse/OFBIZ-11260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11260. -- Fix Version/s: Upcoming Branch Resolution: Resolved Thanks for your contribution [~stregouet] > remove ServiceEventHandler.checkSecureParameter > --- > > Key: OFBIZ-11260 > URL: https://issues.apache.org/jira/browse/OFBIZ-11260 > Project: OFBiz > Issue Type: Bug >Reporter: Samuel Trégouët >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: 01-lint.patch, 02-remove-checkSecureParameter.patch > > > As discussed on d...@ofbiz.apache.org [1] I see no reason to keep this > function, so I suggest to remove it (patch attached with some checkstyle > linting recommendatione applied) > > > [1] > https://lists.apache.org/thread.html/a59689954e2ef5ad8289bfda70bc54ad795dcff6bd12d5aa11755ca4@%3Cdev.ofbiz.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11260) remove ServiceEventHandler.checkSecureParameter
[ https://issues.apache.org/jira/browse/OFBIZ-11260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967036#comment-16967036 ] Mathieu Lirzin commented on OFBIZ-11260: Applied [^01-lint.patch] in commit f93b9ea29a0cc86ebde57f941c6cbdd307a1417e and [^02-remove-checkSecureParameter.patch] in commit 889769593e1fedbf9bd9092550031c72e021d1cf > remove ServiceEventHandler.checkSecureParameter > --- > > Key: OFBIZ-11260 > URL: https://issues.apache.org/jira/browse/OFBIZ-11260 > Project: OFBiz > Issue Type: Bug >Reporter: Samuel Trégouët >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: 01-lint.patch, 02-remove-checkSecureParameter.patch > > > As discussed on d...@ofbiz.apache.org [1] I see no reason to keep this > function, so I suggest to remove it (patch attached with some checkstyle > linting recommendatione applied) > > > [1] > https://lists.apache.org/thread.html/a59689954e2ef5ad8289bfda70bc54ad795dcff6bd12d5aa11755ca4@%3Cdev.ofbiz.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-11260) remove ServiceEventHandler.checkSecureParameter
[ https://issues.apache.org/jira/browse/OFBIZ-11260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin reassigned OFBIZ-11260: -- Assignee: Mathieu Lirzin > remove ServiceEventHandler.checkSecureParameter > --- > > Key: OFBIZ-11260 > URL: https://issues.apache.org/jira/browse/OFBIZ-11260 > Project: OFBiz > Issue Type: Bug >Reporter: Samuel Trégouët >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: 01-lint.patch, 02-remove-checkSecureParameter.patch > > > As discussed on d...@ofbiz.apache.org [1] I see no reason to keep this > function, so I suggest to remove it (patch attached with some checkstyle > linting recommendatione applied) > > > [1] > https://lists.apache.org/thread.html/a59689954e2ef5ad8289bfda70bc54ad795dcff6bd12d5aa11755ca4@%3Cdev.ofbiz.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11264) Refactor Component loading
[ https://issues.apache.org/jira/browse/OFBIZ-11264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11264. -- Fix Version/s: Upcoming Branch Resolution: Fixed Thanks [~stregouet] for your contribution! > Refactor Component loading > -- > > Key: OFBIZ-11264 > URL: https://issues.apache.org/jira/browse/OFBIZ-11264 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Major > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11264_0001-Improved-Import-ComponentDef-and-DependsOnInfo-inner.patch, > OFBIZ-11264_0002-Remove-unnecessary-throws-declarations.patch, > OFBIZ-11264_0003-Delay-the-construction-of-component-classpa.patch, > OFBIZ-11264_0004-Rewrite-ComponentContainer-loadComponentsIn.patch, > OFBIZ-11264_0005-Add-ComponentConfig-toString-to-ease-debugg.patch, > OFBIZ-11264_0006-Turn-DependsOnInfo-into-a-String.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11264) Refactor Component loading
[ https://issues.apache.org/jira/browse/OFBIZ-11264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963134#comment-16963134 ] Mathieu Lirzin commented on OFBIZ-11264: Committed revision 1869180. Committed revision 1869181. Committed revision 1869182. Committed revision 1869183. Committed revision 1869184. Committed revision 1869185. > Refactor Component loading > -- > > Key: OFBIZ-11264 > URL: https://issues.apache.org/jira/browse/OFBIZ-11264 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Major > Attachments: > OFBIZ-11264_0001-Improved-Import-ComponentDef-and-DependsOnInfo-inner.patch, > OFBIZ-11264_0002-Remove-unnecessary-throws-declarations.patch, > OFBIZ-11264_0003-Delay-the-construction-of-component-classpa.patch, > OFBIZ-11264_0004-Rewrite-ComponentContainer-loadComponentsIn.patch, > OFBIZ-11264_0005-Add-ComponentConfig-toString-to-ease-debugg.patch, > OFBIZ-11264_0006-Turn-DependsOnInfo-into-a-String.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11264) Refactor Component loading
[ https://issues.apache.org/jira/browse/OFBIZ-11264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11264: --- Attachment: OFBIZ-11264_0001-Improved-Import-ComponentDef-and-DependsOnInfo-inner.patch OFBIZ-11264_0002-Remove-unnecessary-throws-declarations.patch OFBIZ-11264_0003-Delay-the-construction-of-component-classpa.patch OFBIZ-11264_0004-Rewrite-ComponentContainer-loadComponentsIn.patch OFBIZ-11264_0005-Add-ComponentConfig-toString-to-ease-debugg.patch OFBIZ-11264_0006-Turn-DependsOnInfo-into-a-String.patch > Refactor Component loading > -- > > Key: OFBIZ-11264 > URL: https://issues.apache.org/jira/browse/OFBIZ-11264 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Major > Attachments: > OFBIZ-11264_0001-Improved-Import-ComponentDef-and-DependsOnInfo-inner.patch, > OFBIZ-11264_0002-Remove-unnecessary-throws-declarations.patch, > OFBIZ-11264_0003-Delay-the-construction-of-component-classpa.patch, > OFBIZ-11264_0004-Rewrite-ComponentContainer-loadComponentsIn.patch, > OFBIZ-11264_0005-Add-ComponentConfig-toString-to-ease-debugg.patch, > OFBIZ-11264_0006-Turn-DependsOnInfo-into-a-String.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11264) Refactor Component loading
Mathieu Lirzin created OFBIZ-11264: -- Summary: Refactor Component loading Key: OFBIZ-11264 URL: https://issues.apache.org/jira/browse/OFBIZ-11264 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11167) Use Codenarc to test Groovy code
[ https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962551#comment-16962551 ] Mathieu Lirzin commented on OFBIZ-11167: Nice! > Use Codenarc to test Groovy code > > > Key: OFBIZ-11167 > URL: https://issues.apache.org/jira/browse/OFBIZ-11167 > Project: OFBiz > Issue Type: New Feature > Components: framework >Reporter: Jacques Le Roux >Assignee: Gil Portenseigne >Priority: Minor > Attachments: OFBIZ-11167.patch, main.html, test.html > > > Now that we use Groovy more and more, I think we should really have a look a > Codenarc > https://docs.gradle.org/current/userguide/codenarc_plugin.html > We already discussed it at https://markmail.org/message/uigcpnxqgizhd2oi and > https://markmail.org/message/rp6njoiohkkiodbe > We know it's a crucial task but not an easy but rather a long term one > Here are some interesting links (before I delete my FF tabs group about it) > http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html > http://codenarc.sourceforge.net/codenarc-creating-ruleset.html > https://github.com/gradle/gradle/tree/master/config > https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s > https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11263) Upgrade Groovy 2.4.16 → 2.5.8
[ https://issues.apache.org/jira/browse/OFBIZ-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11263. -- Fix Version/s: Upcoming Branch Resolution: Fixed Committed revision 1869136. > Upgrade Groovy 2.4.16 → 2.5.8 > - > > Key: OFBIZ-11263 > URL: https://issues.apache.org/jira/browse/OFBIZ-11263 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: OFBIZ-11268_Upgrade-Groovy-2.4.16-2.5.8.patch > > > Groovy 2.5.8 is the current Groovy stable release so it would be nice to use > it in OFBiz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11263) Upgrade Groovy 2.4.16 → 2.5.8
[ https://issues.apache.org/jira/browse/OFBIZ-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960629#comment-16960629 ] Mathieu Lirzin commented on OFBIZ-11263: After applying [^OFBIZ-11268_Upgrade-Groovy-2.4.16-2.5.8.patch] I have not detected any issue (integration test, random usage) > Upgrade Groovy 2.4.16 → 2.5.8 > - > > Key: OFBIZ-11263 > URL: https://issues.apache.org/jira/browse/OFBIZ-11263 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: OFBIZ-11268_Upgrade-Groovy-2.4.16-2.5.8.patch > > > Groovy 2.5.8 is the current Groovy stable release so it would be nice to use > it in OFBiz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11263) Upgrade Groovy 2.4.16 → 2.5.8
[ https://issues.apache.org/jira/browse/OFBIZ-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960629#comment-16960629 ] Mathieu Lirzin edited comment on OFBIZ-11263 at 10/27/19 3:25 PM: -- When testing [^OFBIZ-11268_Upgrade-Groovy-2.4.16-2.5.8.patch] I have not detected any issue (integration test, random usage) was (Author: mthl): After applying [^OFBIZ-11268_Upgrade-Groovy-2.4.16-2.5.8.patch] I have not detected any issue (integration test, random usage) > Upgrade Groovy 2.4.16 → 2.5.8 > - > > Key: OFBIZ-11263 > URL: https://issues.apache.org/jira/browse/OFBIZ-11263 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: OFBIZ-11268_Upgrade-Groovy-2.4.16-2.5.8.patch > > > Groovy 2.5.8 is the current Groovy stable release so it would be nice to use > it in OFBiz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11263) Upgrade Groovy 2.4.16 → 2.5.8
[ https://issues.apache.org/jira/browse/OFBIZ-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11263: --- Summary: Upgrade Groovy 2.4.16 → 2.5.8 (was: Upgrade Groovy 2.4.16 → 2.58) > Upgrade Groovy 2.4.16 → 2.5.8 > - > > Key: OFBIZ-11263 > URL: https://issues.apache.org/jira/browse/OFBIZ-11263 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > > Groovy 2.5.8 is the current Groovy stable release so it would be nice to use > it in OFBiz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11263) Upgrade Groovy 2.4.16 → 2.58
Mathieu Lirzin created OFBIZ-11263: -- Summary: Upgrade Groovy 2.4.16 → 2.58 Key: OFBIZ-11263 URL: https://issues.apache.org/jira/browse/OFBIZ-11263 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Mathieu Lirzin Assignee: Mathieu Lirzin Groovy 2.5.8 is the current Groovy stable release so it would be nice to use it in OFBiz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11261) UtilObject#getObjectException does not handle properties properly
[
https://issues.apache.org/jira/browse/OFBIZ-11261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960563#comment-16960563
]
Mathieu Lirzin commented on OFBIZ-11261:
{quote}Just curious, how did you find that bug? Did you had to add a class?
{quote}
I was working on OFBIZ-11262 to remove deprecation warning in
{{SafeObjectInputStream}} and got interested in understanding OFBIZ-10837
underlying problem and how it got fixed. I was suspecting that the
{{SafeObjectInputStream#resolveProxyClass}} override was not necessary because
we are always using the current thread classloader which is what the super
implementation seems to do. As a consequence I decided to write some unit tests
and rewrite the class to remove unnecessary stuff. While doing that I
discovered that bug.
{quote}In your commit you say:
The tests have not been backported from ‘trunk’ because of the way
‘UtilProperties#setPropertyValueInMemory’ work in 18.12.
Because it's related to a security issue covered by OFBIZ-10837 we need bo
backport the fix in all supported releases branches whatever it takes.
{quote}
Sure I should have asked for someone to do the backport, I just drop the ball
because releases before 18.12 fail to build on my system because of a Gradle
issue
{code:java}
$ ./gradlew
FAILURE: Build failed with an exception.
* What went wrong:
Failed to load native library 'libnative-platform.so' for Linux amd64.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output.
{code}
Thanks for taking care of the backport.
> UtilObject#getObjectException does not handle properties properly
> -
>
> Key: OFBIZ-11261
> URL: https://issues.apache.org/jira/browse/OFBIZ-11261
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Major
> Fix For: Upcoming Branch, Release Branch 18.12
>
> Attachments:
> OFBIZ-11261_0001-Improved-Write-tests-for-UtilObject-getObjectExcepti.patch,
> OFBIZ-11261_0002-Fixed-Handle-whitelist-of-serializable-classes-from-.patch,
> OFBIZ-11261_0003-Improved-Refactor-UtilObject-getObjectException.patch
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11067) Migrate integration tests to unit tests when possible
[
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960440#comment-16960440
]
Mathieu Lirzin commented on OFBIZ-11067:
Committed
[^OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch] in
revision 1869022.
Committed
[^OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch] in
revision 1869023.
The remaining classes to convert to unit test before closing this ticket are:
* FlexibleStringExpanderTests
* FlexibleMapAccessorTests
> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments:
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch,
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch,
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch,
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch,
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch,
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch,
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch,
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch,
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch,
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch
>
>
> In OFBiz there are both unit tests and integration tests which are
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}.
> However some integration tests are in fact unit tests that doesn't depend on
> the entity and service engines. Those unit tests should run on the their
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3
> which is what is done for the integration test suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11067) Migrate integration tests to unit tests when possible
[
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu Lirzin updated OFBIZ-11067:
---
Attachment:
OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch
OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch
> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments:
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch,
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch,
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch,
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch,
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch,
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch,
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch,
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch,
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch,
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch,
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch
>
>
> In OFBiz there are both unit tests and integration tests which are
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}.
> However some integration tests are in fact unit tests that doesn't depend on
> the entity and service engines. Those unit tests should run on the their
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3
> which is what is done for the integration test suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-11262) Remove compilation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin closed OFBIZ-11262. -- Fix Version/s: Upcoming Branch Resolution: Resolved Committed revision 1869006, 1869007, 1869008, 1869009, 1869010 > Remove compilation warnings > --- > > Key: OFBIZ-11262 > URL: https://issues.apache.org/jira/browse/OFBIZ-11262 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-11262_0001-Improved-Do-not-use-deprecated-javax.security.cert.X.patch, > OFBIZ-11262_0002-Improved-Do-not-use-deprecated-Proxyclass-getConstru.patch, > OFBIZ-11262_0003-Improved-Do-not-use-deprecated-Class-newInstance.patch, > OFBIZ-11262_0004-Improved-Use-utilitary-OFBizTestCase-getLogin-in-Ser.patch, > OFBIZ-11262_0005-Improved-Define-specific-maxErrors-for-main-test-sou.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11262) Remove compilation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lirzin updated OFBIZ-11262: --- Attachment: OFBIZ-11262_0001-Improved-Do-not-use-deprecated-javax.security.cert.X.patch OFBIZ-11262_0002-Improved-Do-not-use-deprecated-Proxyclass-getConstru.patch OFBIZ-11262_0003-Improved-Do-not-use-deprecated-Class-newInstance.patch OFBIZ-11262_0004-Improved-Use-utilitary-OFBizTestCase-getLogin-in-Ser.patch OFBIZ-11262_0005-Improved-Define-specific-maxErrors-for-main-test-sou.patch > Remove compilation warnings > --- > > Key: OFBIZ-11262 > URL: https://issues.apache.org/jira/browse/OFBIZ-11262 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Mathieu Lirzin >Priority: Minor > Attachments: > OFBIZ-11262_0001-Improved-Do-not-use-deprecated-javax.security.cert.X.patch, > OFBIZ-11262_0002-Improved-Do-not-use-deprecated-Proxyclass-getConstru.patch, > OFBIZ-11262_0003-Improved-Do-not-use-deprecated-Class-newInstance.patch, > OFBIZ-11262_0004-Improved-Use-utilitary-OFBizTestCase-getLogin-in-Ser.patch, > OFBIZ-11262_0005-Improved-Define-specific-maxErrors-for-main-test-sou.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
