[jira] [Commented] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849796#comment-15849796 ] Taher Alkhateeb commented on OFBIZ-9182: Hi Nicolas, What would be the purpose of getting the latest plugin form version control to a release? > create a separate svn repository for OFBiz official plugins > --- > > Key: OFBIZ-9182 > URL: https://issues.apache.org/jira/browse/OFBIZ-9182 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Upcoming Release >Reporter: Taher Alkhateeb >Priority: Minor > Labels: gradle, plugins, subversion > Attachments: OFBIZ-9182-subversion-embedded.patch > > > This issue is related to the discussion found in [this > thread|https://s.apache.org/aohk] in which the community approved > restructuring our repositories. To achieve this task the following needs to > be done (in this order) > # Update the gradle scripts to assume that no plugins exist in the plugins > directory by default and no component-load.xml exists. It should follow the > same logic in loading the components as found in the ComponentContainer > class. Also the activation and deactivation of plugins happens in > ofbiz-component.xml, not in component-load.xml > # Add a new task to gradle called pullPluginSource that retrieves a plugin > from subversion and defaults to the official plugins repository of Apache > OFBiz. This task mostly serve "Trunk" because it always needs the latest > source code of the plugins. > # delete plugins/component-load.xml > # move all plugins to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins > # move the core framework to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework > # fix buildbot to point to the new framework location > # update documentation where applicable including README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OFBIZ-9196) Regression: the testIntegration Gradle taks shoud not use/block the ports
Jacques Le Roux created OFBIZ-9196: -- Summary: Regression: the testIntegration Gradle taks shoud not use/block the ports Key: OFBIZ-9196 URL: https://issues.apache.org/jira/browse/OFBIZ-9196 Project: OFBiz Issue Type: Bug Components: Gradle Affects Versions: Release Branch 16.11, Trunk Reporter: Jacques Le Roux Priority: Minor Fix For: Upcoming Release, 16.11.02 We got an issue on Buildbot because of a Puppet misconfiguration which was always using the port 8080. Pre-gradle OFBiz tests were still running fine on Buildbot. Before the Puppet misconfiguration fix by infra (INFRA-13402) bo bypass this issue I tried last weekend to use portoffset in Gradle versions. From the documentation, it's theoretically possible but does not work. Taher suggested, to get back to the previous behaviour were tests were not using/blocking the 8080 port. Taher suggested to have a look into Config.java... It's a regression because it was nice to not have ports blocked during tests, as it was before Gradle. So you can use another (or more) OFBiz instance while running tests, and vice-versa. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OFBIZ-9197) Javadoc creation issue
Jacques Le Roux created OFBIZ-9197: -- Summary: Javadoc creation issue Key: OFBIZ-9197 URL: https://issues.apache.org/jira/browse/OFBIZ-9197 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Fix For: Upcoming Release While Buildbot was blocked (INFRA-13402) we did not spot that we have a Javadoc creation issue with trunk (we generate Javadoc only for trunk so far) I tried to revert to r1780691 (last commit before last Gradle change) to no avail This is currently blocking Buildbot. I'll temporarily bypass the Javadoc creation issue Buildbot task and will put it back when the issue will be fixed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OFBIZ-9196) Regression: the testIntegration Gradle taks shoud not use/block the ports
[ https://issues.apache.org/jira/browse/OFBIZ-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9196: --- Description: We got an issue on Buildbot because of a Puppet misconfiguration which was always using the port 8080. Pre-gradle OFBiz tests were still running fine on Buildbot. Before the Puppet misconfiguration fix by infra (INFRA-13402), to bypass this issue I tried last weekend to use portoffset in Gradle versions. From the documentation, it's theoretically possible but does not work. Taher suggested, to get back to the previous behaviour were tests were not using/blocking the 8080 port, and to have a look into Config.java... It's a regression because it was nice to not have ports blocked during tests, as it was before Gradle. So you can use another (or more) OFBiz instance while running tests, and vice-versa. was: We got an issue on Buildbot because of a Puppet misconfiguration which was always using the port 8080. Pre-gradle OFBiz tests were still running fine on Buildbot. Before the Puppet misconfiguration fix by infra (INFRA-13402) bo bypass this issue I tried last weekend to use portoffset in Gradle versions. From the documentation, it's theoretically possible but does not work. Taher suggested, to get back to the previous behaviour were tests were not using/blocking the 8080 port. Taher suggested to have a look into Config.java... It's a regression because it was nice to not have ports blocked during tests, as it was before Gradle. So you can use another (or more) OFBiz instance while running tests, and vice-versa. > Regression: the testIntegration Gradle taks shoud not use/block the ports > - > > Key: OFBIZ-9196 > URL: https://issues.apache.org/jira/browse/OFBIZ-9196 > Project: OFBiz > Issue Type: Bug > Components: Gradle >Affects Versions: Trunk, Release Branch 16.11 >Reporter: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Release, 16.11.02 > > > We got an issue on Buildbot because of a Puppet misconfiguration which was > always using the port 8080. Pre-gradle OFBiz tests were still running fine on > Buildbot. > Before the Puppet misconfiguration fix by infra (INFRA-13402), to bypass this > issue I tried last weekend to use portoffset in Gradle versions. From the > documentation, it's theoretically possible but does not work. > Taher suggested, to get back to the previous behaviour were tests were not > using/blocking the 8080 port, and to have a look into Config.java... > It's a regression because it was nice to not have ports blocked during tests, > as it was before Gradle. So you can use another (or more) OFBiz instance > while running tests, and vice-versa. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OFBIZ-9198) Missing file results in infinite loop
Ingo Wolfmayr created OFBIZ-9198: Summary: Missing file results in infinite loop Key: OFBIZ-9198 URL: https://issues.apache.org/jira/browse/OFBIZ-9198 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 16.11, Release Branch 15.12, Trunk, Release Branch 13.07 Reporter: Ingo Wolfmayr Priority: Critical When accessing a file/image in ecommerce (only seo version) that is physically missing or the dataresource attribute isPublic=="N" the request results in an infinite loop. Demo data: Call: /ecomseo/testbild-content /ecomseo/stream?contentId=test I found that because I had server problems (server down), so it is quite easy to kill the server by streaming a not existing contentId via via the ecomseo app. /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OFBIZ-9198) Missing file results in infinite loop
[ https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Wolfmayr updated OFBIZ-9198: - Attachment: errror.txt Part of the error message > Missing file results in infinite loop > - > > Key: OFBIZ-9198 > URL: https://issues.apache.org/jira/browse/OFBIZ-9198 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Ingo Wolfmayr >Priority: Critical > Attachments: errror.txt > > > When accessing a file/image in ecommerce (only seo version) that is > physically missing or the dataresource attribute isPublic=="N" the request > results in an infinite loop. > Demo data: > statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test > Image" objectInfo="PATH TO FILE" isPublic="N" /> > dataResourceId="testurl" statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" > objectInfo="/testbild-content" isPublic="N"/> > Call: > /ecomseo/testbild-content > /ecomseo/stream?contentId=test > I found that because I had server problems (server down), so it is quite easy > to kill the server by streaming a not existing contentId via via the ecomseo > app. > /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OFBIZ-9198) Missing file results in infinite loop
[ https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Wolfmayr updated OFBIZ-9198: - Description: When accessing a file/image in ecommerce (only seo version) that is physically missing or the dataresource attribute isPublic=="N" the request results in an infinite loop. Demo data: Call: /ecomseo/testbild-content /ecomseo/stream?contentId=test I found that because I had server problems (server down), so it is quite easy to kill the server by streaming a not existing contentId via via the ecomseo app. /ecomseo/stream?contentId=test1 was: When accessing a file/image in ecommerce (only seo version) that is physically missing or the dataresource attribute isPublic=="N" the request results in an infinite loop. Demo data: Call: /ecomseo/testbild-content /ecomseo/stream?contentId=test I found that because I had server problems (server down), so it is quite easy to kill the server by streaming a not existing contentId via via the ecomseo app. /ecomseo/stream?contentId=test1 > Missing file results in infinite loop > - > > Key: OFBIZ-9198 > URL: https://issues.apache.org/jira/browse/OFBIZ-9198 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Ingo Wolfmayr >Priority: Critical > Attachments: errror.txt > > > When accessing a file/image in ecommerce (only seo version) that is > physically missing or the dataresource attribute isPublic=="N" the request > results in an infinite loop. > Demo data: > statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test > Image" objectInfo="PATH TO FILE" isPublic="N" /> > dataResourceId="testurl" statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" > objectInfo="/testbild-content" isPublic="N"/> > contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/> > Call: > /ecomseo/testbild-content > /ecomseo/stream?contentId=test > I found that because I had server problems (server down), so it is quite easy > to kill the server by streaming a not existing contentId via via the ecomseo > app. > /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OFBIZ-9198) Missing file results in infinite loop
[ https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9198: -- Assignee: Jacques Le Roux > Missing file results in infinite loop > - > > Key: OFBIZ-9198 > URL: https://issues.apache.org/jira/browse/OFBIZ-9198 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Ingo Wolfmayr >Assignee: Jacques Le Roux >Priority: Critical > Attachments: errror.txt > > > When accessing a file/image in ecommerce (only seo version) that is > physically missing or the dataresource attribute isPublic=="N" the request > results in an infinite loop. > Demo data: > statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test > Image" objectInfo="PATH TO FILE" isPublic="N" /> > dataResourceId="testurl" statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" > objectInfo="/testbild-content" isPublic="N"/> > contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/> > Call: > /ecomseo/testbild-content > /ecomseo/stream?contentId=test > I found that because I had server problems (server down), so it is quite easy > to kill the server by streaming a not existing contentId via via the ecomseo > app. > /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OFBIZ-9198) Missing file results in infinite loop
[
https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850552#comment-15850552
]
Jacques Le Roux commented on OFBIZ-9198:
Ouch! It's not exactly an infinite loop. Here it tooks 4+ seconds
{code}
2017-02-02 22:29:18,344 |http-nio-8443-exec-8 |ControlServlet
|T| [[[stream(Domain:https://localhost)] Request Begun, encoding=[UTF-8]-
total:0.0,since last(Begin):0.0]]
[...]
2017-02-02 22:29:22,410 |http-nio-8443-exec-8 |ControlServlet
|T| [[[stream(Domain:https://localhost)] Request Done- total:4.066,since
last([stream(Domain:ht...):4.066]]
{code}
But indeed it can be easily used with a massive DDOS. So this is a security
issue and since it's already disclosed I make it a subtask of OFBIZ-1525
Please Ingo note that in case of security issues the ASF has some logical
recommendation that we relay in the "Security Vulnerabilities" section at
http://ofbiz.apache.org/download.html
Thanks
> Missing file results in infinite loop
> -
>
> Key: OFBIZ-9198
> URL: https://issues.apache.org/jira/browse/OFBIZ-9198
> Project: OFBiz
> Issue Type: Bug
> Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12,
> Release Branch 16.11
>Reporter: Ingo Wolfmayr
>Assignee: Jacques Le Roux
>Priority: Critical
> Attachments: errror.txt
>
>
> When accessing a file/image in ecommerce (only seo version) that is
> physically missing or the dataresource attribute isPublic=="N" the request
> results in an infinite loop.
> Demo data:
> statusId="CTNT_PUBLISHED"/>
> dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test
> Image" objectInfo="PATH TO FILE" isPublic="N" />
> dataResourceId="testurl" statusId="CTNT_PUBLISHED"/>
> dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED"
> objectInfo="/testbild-content" isPublic="N"/>
> contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/>
> Call:
> /ecomseo/testbild-content
> /ecomseo/stream?contentId=test
> I found that because I had server problems (server down), so it is quite easy
> to kill the server by streaming a not existing contentId via via the ecomseo
> app.
> /ecomseo/stream?contentId=test1
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OFBIZ-9198) Missing file results in infinite loop
[ https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-9198: --- Issue Type: Sub-task (was: Bug) Parent: OFBIZ-1525 > Missing file results in infinite loop > - > > Key: OFBIZ-9198 > URL: https://issues.apache.org/jira/browse/OFBIZ-9198 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Ingo Wolfmayr >Assignee: Jacques Le Roux >Priority: Critical > Attachments: errror.txt > > > When accessing a file/image in ecommerce (only seo version) that is > physically missing or the dataresource attribute isPublic=="N" the request > results in an infinite loop. > Demo data: > statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test > Image" objectInfo="PATH TO FILE" isPublic="N" /> > dataResourceId="testurl" statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" > objectInfo="/testbild-content" isPublic="N"/> > contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/> > Call: > /ecomseo/testbild-content > /ecomseo/stream?contentId=test > I found that because I had server problems (server down), so it is quite easy > to kill the server by streaming a not existing contentId via via the ecomseo > app. > /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OFBIZ-9198) Missing file results in infinite loop
[
https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850552#comment-15850552
]
Jacques Le Roux edited comment on OFBIZ-9198 at 2/2/17 9:41 PM:
Ouch! It's not exactly an infinite loop. Here it tooks 4+ seconds
{code}
2017-02-02 22:29:18,344 |http-nio-8443-exec-8 |ControlServlet
|T| [[[stream(Domain:https://localhost)] Request Begun, encoding=[UTF-8]-
total:0.0,since last(Begin):0.0]]
[...]
2017-02-02 22:29:22,410 |http-nio-8443-exec-8 |ControlServlet
|T| [[[stream(Domain:https://localhost)] Request Done- total:4.066,since
last([stream(Domain:ht...):4.066]]
{code}
But indeed it can be easily used with a massive DDOS. So this is a security
issue and since it's already disclosed I make it a subtask of OFBIZ-1525
Please Ingo note that in case of security issues the ASF has some logical
recommendations that we relay in the "Security Vulnerabilities" section at
http://ofbiz.apache.org/download.html
Thanks
was (Author: jacques.le.roux):
Ouch! It's not exactly an infinite loop. Here it tooks 4+ seconds
{code}
2017-02-02 22:29:18,344 |http-nio-8443-exec-8 |ControlServlet
|T| [[[stream(Domain:https://localhost)] Request Begun, encoding=[UTF-8]-
total:0.0,since last(Begin):0.0]]
[...]
2017-02-02 22:29:22,410 |http-nio-8443-exec-8 |ControlServlet
|T| [[[stream(Domain:https://localhost)] Request Done- total:4.066,since
last([stream(Domain:ht...):4.066]]
{code}
But indeed it can be easily used with a massive DDOS. So this is a security
issue and since it's already disclosed I make it a subtask of OFBIZ-1525
Please Ingo note that in case of security issues the ASF has some logical
recommendation that we relay in the "Security Vulnerabilities" section at
http://ofbiz.apache.org/download.html
Thanks
> Missing file results in infinite loop
> -
>
> Key: OFBIZ-9198
> URL: https://issues.apache.org/jira/browse/OFBIZ-9198
> Project: OFBiz
> Issue Type: Sub-task
> Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12,
> Release Branch 16.11
>Reporter: Ingo Wolfmayr
>Assignee: Jacques Le Roux
>Priority: Critical
> Attachments: errror.txt
>
>
> When accessing a file/image in ecommerce (only seo version) that is
> physically missing or the dataresource attribute isPublic=="N" the request
> results in an infinite loop.
> Demo data:
> statusId="CTNT_PUBLISHED"/>
> dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test
> Image" objectInfo="PATH TO FILE" isPublic="N" />
> dataResourceId="testurl" statusId="CTNT_PUBLISHED"/>
> dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED"
> objectInfo="/testbild-content" isPublic="N"/>
> contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/>
> Call:
> /ecomseo/testbild-content
> /ecomseo/stream?contentId=test
> I found that because I had server problems (server down), so it is quite easy
> to kill the server by streaming a not existing contentId via via the ecomseo
> app.
> /ecomseo/stream?contentId=test1
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847573#comment-15847573 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:05 PM: - Hi Taher, Just thinking out loud for now... We don't need 2 Buildbot scripts if we can use svn externals http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html Note about automation: currently https://github.com/martoe/gradle-svntools-plugin does not support svn propedit, we could contribute, it's groovy code after all... BTW, there is a similar solutions with Git if we need it later https://stackoverflow.com/questions/571232/svnexternals-equivalent-in-git I have one worry, what about people relying on branches (evolving with new features eg R16.11) and not releases (fixed but bugs, eg 16.11.01) ? It seems they will loose something, don't they? Fortunately svn externals allows to define specific revisions. For instance we could define a revision for each plugin. As you said maybe too much, but maybe also convenient. Anyway this needs at least to be evaluated (ie more than just thinking out loud late in the evening...) was (Author: jacques.le.roux): Hi Taher, Just thinking out loud for now... We don't need 2 Buildbot scripts if we can use svn externals http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html Note about automation: currently https://github.com/martoe/gradle-svntools-plugin does not support svn propedit, we could contribute, it's groovy code after all... BTW, there is a similar solutions with Git if we need it later https://stackoverflow.com/questions/571232/svnexternals-equivalent-in-git I have one worry, what about people relying on branches (eg evolving with new features R16.11) and not release (fixed but bug 16.11.01) ? It seems they will loose something, don't they? Fortunately svn externals allows to define specific revisions. For instance we could define a revision for each plugin. As you said maybe too much, but maybe also convenient. Anyway this needs at least to be evaluated (ie more than just thinking out loud late in the evening...) > create a separate svn repository for OFBiz official plugins > --- > > Key: OFBIZ-9182 > URL: https://issues.apache.org/jira/browse/OFBIZ-9182 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Upcoming Release >Reporter: Taher Alkhateeb >Priority: Minor > Labels: gradle, plugins, subversion > Attachments: OFBIZ-9182-subversion-embedded.patch > > > This issue is related to the discussion found in [this > thread|https://s.apache.org/aohk] in which the community approved > restructuring our repositories. To achieve this task the following needs to > be done (in this order) > # Update the gradle scripts to assume that no plugins exist in the plugins > directory by default and no component-load.xml exists. It should follow the > same logic in loading the components as found in the ComponentContainer > class. Also the activation and deactivation of plugins happens in > ofbiz-component.xml, not in component-load.xml > # Add a new task to gradle called pullPluginSource that retrieves a plugin > from subversion and defaults to the official plugins repository of Apache > OFBiz. This task mostly serve "Trunk" because it always needs the latest > source code of the plugins. > # delete plugins/component-load.xml > # move all plugins to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins > # move the core framework to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework > # fix buildbot to point to the new framework location > # update documentation where applicable including README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850586#comment-15850586 ] Jacques Le Roux commented on OFBIZ-9182: Nicolas, that's why svn externals is perfect in this case, because it opens all possibilities svn provides. You can either use it with a revision (for a published release you can use its tags) or w/o which means taking HEAD. > create a separate svn repository for OFBiz official plugins > --- > > Key: OFBIZ-9182 > URL: https://issues.apache.org/jira/browse/OFBIZ-9182 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Upcoming Release >Reporter: Taher Alkhateeb >Priority: Minor > Labels: gradle, plugins, subversion > Attachments: OFBIZ-9182-subversion-embedded.patch > > > This issue is related to the discussion found in [this > thread|https://s.apache.org/aohk] in which the community approved > restructuring our repositories. To achieve this task the following needs to > be done (in this order) > # Update the gradle scripts to assume that no plugins exist in the plugins > directory by default and no component-load.xml exists. It should follow the > same logic in loading the components as found in the ComponentContainer > class. Also the activation and deactivation of plugins happens in > ofbiz-component.xml, not in component-load.xml > # Add a new task to gradle called pullPluginSource that retrieves a plugin > from subversion and defaults to the official plugins repository of Apache > OFBiz. This task mostly serve "Trunk" because it always needs the latest > source code of the plugins. > # delete plugins/component-load.xml > # move all plugins to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins > # move the core framework to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework > # fix buildbot to point to the new framework location > # update documentation where applicable including README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850586#comment-15850586 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:12 PM: - Nicolas, that's why svn externals is perfect in this case, because it opens all possibilities svn provides. When associating a plugin, you can either use a revision (for a published release you can use its tags) or w/o revision which means taking HEAD. We just miss the automation. Because so far the Gradle plugin has no task for properties. And properties are very powerful features of Svn, often neglected. Disclaimer: I must say I have not yet a clear picture in mind, just ideas... was (Author: jacques.le.roux): Nicolas, that's why svn externals is perfect in this case, because it opens all possibilities svn provides. You can either use it with a revision (for a published release you can use its tags) or w/o which means taking HEAD. > create a separate svn repository for OFBiz official plugins > --- > > Key: OFBIZ-9182 > URL: https://issues.apache.org/jira/browse/OFBIZ-9182 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Upcoming Release >Reporter: Taher Alkhateeb >Priority: Minor > Labels: gradle, plugins, subversion > Attachments: OFBIZ-9182-subversion-embedded.patch > > > This issue is related to the discussion found in [this > thread|https://s.apache.org/aohk] in which the community approved > restructuring our repositories. To achieve this task the following needs to > be done (in this order) > # Update the gradle scripts to assume that no plugins exist in the plugins > directory by default and no component-load.xml exists. It should follow the > same logic in loading the components as found in the ComponentContainer > class. Also the activation and deactivation of plugins happens in > ofbiz-component.xml, not in component-load.xml > # Add a new task to gradle called pullPluginSource that retrieves a plugin > from subversion and defaults to the official plugins repository of Apache > OFBiz. This task mostly serve "Trunk" because it always needs the latest > source code of the plugins. > # delete plugins/component-load.xml > # move all plugins to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins > # move the core framework to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework > # fix buildbot to point to the new framework location > # update documentation where applicable including README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850586#comment-15850586 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:19 PM: - Nicolas, that's why svn externals is perfect in this case, because it opens all possibilities svn provides. When associating a plugin, you can either use a revision (for a published release you can use its tags) or w/o revision which means taking HEAD. Ah yes, answering your point: people not able to use a checkout are indeed in another situation. But we could document it by simply suggesting to check out using the release tag. It's the same thing, just not packaged, and with the svn bagages. The svn bagages can be droppped later by using an export, note that the required svn externals (for the used plugins) will be also exported by default. Now it's not an official way to do things... Because only releases are published. So we have indeed to think about this aspect. Even if for most people using OFBiz it's not really an issue. We also miss the automation. Because so far the Gradle plugin has no task for properties. Properties are very powerful features of Svn, often neglected. Disclaimer: I must say I have not yet a clear picture in mind, just ideas... was (Author: jacques.le.roux): Nicolas, that's why svn externals is perfect in this case, because it opens all possibilities svn provides. When associating a plugin, you can either use a revision (for a published release you can use its tags) or w/o revision which means taking HEAD. We just miss the automation. Because so far the Gradle plugin has no task for properties. And properties are very powerful features of Svn, often neglected. Disclaimer: I must say I have not yet a clear picture in mind, just ideas... > create a separate svn repository for OFBiz official plugins > --- > > Key: OFBIZ-9182 > URL: https://issues.apache.org/jira/browse/OFBIZ-9182 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Upcoming Release >Reporter: Taher Alkhateeb >Priority: Minor > Labels: gradle, plugins, subversion > Attachments: OFBIZ-9182-subversion-embedded.patch > > > This issue is related to the discussion found in [this > thread|https://s.apache.org/aohk] in which the community approved > restructuring our repositories. To achieve this task the following needs to > be done (in this order) > # Update the gradle scripts to assume that no plugins exist in the plugins > directory by default and no component-load.xml exists. It should follow the > same logic in loading the components as found in the ComponentContainer > class. Also the activation and deactivation of plugins happens in > ofbiz-component.xml, not in component-load.xml > # Add a new task to gradle called pullPluginSource that retrieves a plugin > from subversion and defaults to the official plugins repository of Apache > OFBiz. This task mostly serve "Trunk" because it always needs the latest > source code of the plugins. > # delete plugins/component-load.xml > # move all plugins to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins > # move the core framework to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework > # fix buildbot to point to the new framework location > # update documentation where applicable including README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850586#comment-15850586 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:25 PM: - Nicolas, Has Taher suggested, people using releases would have available corresponding plugins released. They don't need to use pullPluginSource only pullPlugin In other cases (relying on checked out sources), svn externals is perfect. Because it opens all possibilities svn provides. When associating a plugin, you can either use a revision or w/o revision which means taking HEAD. We though miss the automation. Because so far the Gradle plugin has no task for properties. Properties are very powerful features of Svn, often neglected. Disclaimer: I must say I have not yet a clear picture in mind, just ideas... was (Author: jacques.le.roux): Nicolas, that's why svn externals is perfect in this case, because it opens all possibilities svn provides. When associating a plugin, you can either use a revision (for a published release you can use its tags) or w/o revision which means taking HEAD. Ah yes, answering your point: people not able to use a checkout are indeed in another situation. But we could document it by simply suggesting to check out using the release tag. It's the same thing, just not packaged, and with the svn bagages. The svn bagages can be droppped later by using an export, note that the required svn externals (for the used plugins) will be also exported by default. Now it's not an official way to do things... Because only releases are published. So we have indeed to think about this aspect. Even if for most people using OFBiz it's not really an issue. We also miss the automation. Because so far the Gradle plugin has no task for properties. Properties are very powerful features of Svn, often neglected. Disclaimer: I must say I have not yet a clear picture in mind, just ideas... > create a separate svn repository for OFBiz official plugins > --- > > Key: OFBIZ-9182 > URL: https://issues.apache.org/jira/browse/OFBIZ-9182 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Upcoming Release >Reporter: Taher Alkhateeb >Priority: Minor > Labels: gradle, plugins, subversion > Attachments: OFBIZ-9182-subversion-embedded.patch > > > This issue is related to the discussion found in [this > thread|https://s.apache.org/aohk] in which the community approved > restructuring our repositories. To achieve this task the following needs to > be done (in this order) > # Update the gradle scripts to assume that no plugins exist in the plugins > directory by default and no component-load.xml exists. It should follow the > same logic in loading the components as found in the ComponentContainer > class. Also the activation and deactivation of plugins happens in > ofbiz-component.xml, not in component-load.xml > # Add a new task to gradle called pullPluginSource that retrieves a plugin > from subversion and defaults to the official plugins repository of Apache > OFBiz. This task mostly serve "Trunk" because it always needs the latest > source code of the plugins. > # delete plugins/component-load.xml > # move all plugins to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins > # move the core framework to a new repository called > http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework > # fix buildbot to point to the new framework location > # update documentation where applicable including README.md -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OFBIZ-9198) Missing file results in error
[ https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ingo Wolfmayr updated OFBIZ-9198: - Description: When accessing a file/image in ecommerce (only seo version) that is physically missing or the dataresource attribute isPublic=="N" the request results in an a loop. Demo data: Call: /ecomseo/testbild-content /ecomseo/stream?contentId=test I found that because I had server problems (server down), so it is quite easy to kill the server by streaming a not existing contentId via via the ecomseo app. /ecomseo/stream?contentId=test1 was: When accessing a file/image in ecommerce (only seo version) that is physically missing or the dataresource attribute isPublic=="N" the request results in an infinite loop. Demo data: Call: /ecomseo/testbild-content /ecomseo/stream?contentId=test I found that because I had server problems (server down), so it is quite easy to kill the server by streaming a not existing contentId via via the ecomseo app. /ecomseo/stream?contentId=test1 Summary: Missing file results in error (was: Missing file results in infinite loop) > Missing file results in error > - > > Key: OFBIZ-9198 > URL: https://issues.apache.org/jira/browse/OFBIZ-9198 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Ingo Wolfmayr >Assignee: Jacques Le Roux >Priority: Critical > Attachments: errror.txt > > > When accessing a file/image in ecommerce (only seo version) that is > physically missing or the dataresource attribute isPublic=="N" the request > results in an a loop. > Demo data: > statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test > Image" objectInfo="PATH TO FILE" isPublic="N" /> > dataResourceId="testurl" statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" > objectInfo="/testbild-content" isPublic="N"/> > contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/> > Call: > /ecomseo/testbild-content > /ecomseo/stream?contentId=test > I found that because I had server problems (server down), so it is quite easy > to kill the server by streaming a not existing contentId via via the ecomseo > app. > /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OFBIZ-9198) Missing file results in error
[ https://issues.apache.org/jira/browse/OFBIZ-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850680#comment-15850680 ] Ingo Wolfmayr commented on OFBIZ-9198: -- Hi Jaques, your right, it took a little longer on my dev environment ~ between 40 to 80 seconds. I did not wait for it to finish before. I changed the title. Ingo > Missing file results in error > - > > Key: OFBIZ-9198 > URL: https://issues.apache.org/jira/browse/OFBIZ-9198 > Project: OFBiz > Issue Type: Sub-task > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 13.07, Trunk, Release Branch 15.12, > Release Branch 16.11 >Reporter: Ingo Wolfmayr >Assignee: Jacques Le Roux >Priority: Critical > Attachments: errror.txt > > > When accessing a file/image in ecommerce (only seo version) that is > physically missing or the dataresource attribute isPublic=="N" the request > results in an a loop. > Demo data: > statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" dataResourceName="Test > Image" objectInfo="PATH TO FILE" isPublic="N" /> > dataResourceId="testurl" statusId="CTNT_PUBLISHED"/> > dataTemplateTypeId="NONE" statusId="CTNT_PUBLISHED" > objectInfo="/testbild-content" isPublic="N"/> > contentAssocTypeId="ALTERNATE_URL" fromDate="2006-09-22 00:00:00.0"/> > Call: > /ecomseo/testbild-content > /ecomseo/stream?contentId=test > I found that because I had server problems (server down), so it is quite easy > to kill the server by streaming a not existing contentId via via the ecomseo > app. > /ecomseo/stream?contentId=test1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[
https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851083#comment-15851083
]
Jacques Le Roux commented on OFBIZ-9182:
OK, it clear to me now. We don't need pullPluginSource if we set a svn external
for the plugins repo.
Taher said
{quote}
There are two ways to pull a plugin from source: Either have subversion
installed on the machine and use exec
{...}
OR use an embedded subversion based on Java and hence avoid dependence on
environment.
{quote}
Actually people should not have to worry about using "exec" manually. That's
what a svn external for the plugins repo would do automatically for them,
checking out the whole plugins dir without any efforts and even noticing it.
I recap:
# People using released packages use pullPlugin to get the released plugin/s
they want (and more because of plugins interdependencies)
# People not using released packages, ie using checked out working copies,
don't have to worry they get all plugins with the svn externals as it is now.
The dependencies will be resolved while building as it is now
But then for svn externals, what for people who want to use only one or few
plugins? Then maybe we need to reconsider component.load in plugins dir and
de/activatePlugin tasks...
So the decision about using svn external or pullPluginSource is up to the
community.
Maybe pullPluginSource is clearer because you easily get only what you want,
but what about plugins inter-dependencies? Also if you want a lot of plugins
it's kinda a pain. For now we have "only" 19 plugins but what's next?
To summarize, as long as plugins inter-dependencies will not be resolved svn
externals is more convenient.
About resolving plugins inter-dependencies, is it even possible (we finally let
it be in applications)? Consider DLL and Jar hells, even Microsoft and Sun were
not able to cleanly do it. And now you have Java 9 and its modules coming:
http://blog.codefx.org/java/dev/will-there-be-module-hell/
> create a separate svn repository for OFBiz official plugins
> ---
>
> Key: OFBIZ-9182
> URL: https://issues.apache.org/jira/browse/OFBIZ-9182
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Upcoming Release
>Reporter: Taher Alkhateeb
>Priority: Minor
> Labels: gradle, plugins, subversion
> Attachments: OFBIZ-9182-subversion-embedded.patch
>
>
> This issue is related to the discussion found in [this
> thread|https://s.apache.org/aohk] in which the community approved
> restructuring our repositories. To achieve this task the following needs to
> be done (in this order)
> # Update the gradle scripts to assume that no plugins exist in the plugins
> directory by default and no component-load.xml exists. It should follow the
> same logic in loading the components as found in the ComponentContainer
> class. Also the activation and deactivation of plugins happens in
> ofbiz-component.xml, not in component-load.xml
> # Add a new task to gradle called pullPluginSource that retrieves a plugin
> from subversion and defaults to the official plugins repository of Apache
> OFBiz. This task mostly serve "Trunk" because it always needs the latest
> source code of the plugins.
> # delete plugins/component-load.xml
> # move all plugins to a new repository called
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins
> # move the core framework to a new repository called
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework
> # fix buildbot to point to the new framework location
> # update documentation where applicable including README.md
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
