[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779001#comment-17779001 ] Markus Karg commented on FOP-3084: -- I would like to kindly ask if we could continue this discussion after more than one year of consideration. As I already wrote, the proposed workaround is _dysfunctional_ for embedded SVG, so we _do_ need an API change. I would really be happy if [~ssteiner] could chime in. Thanks a lot! :) > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570707#comment-17570707 ] Markus Karg commented on FOP-3084: -- It would be nice if the FOP Committers would chime in here and either agree upon the necessity to extend the API _or_ provide a *completely* functional workaround that does not excluded embedded SVG. Thanks. :) > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[
https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570694#comment-17570694
]
Markus Karg commented on FOP-3084:
--
BTW, I even tried to use a fake folder with file: schema to get around the
problem with the unknown protocol. But this time it is Batik which complains
that the fake folder does not exists. As you can see, your proposed solution
just will open another can of worms in turn.
{{org.apache.batik.bridge.BridgeException: file:/MY_FAKE_FOLDER/:-1}}
I think it is proven that there cannot any other solution than an API change! :)
> Override baseURI per FOP instance
> -
>
> Key: FOP-3084
> URL: https://issues.apache.org/jira/browse/FOP-3084
> Project: FOP
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Markus Karg
>Priority: Major
>
> There is a best practice to reuse FOP Factory instances for optimal
> performance. But doing so effectively applies the same baseURI (the one used
> at factory creation) to all FOP instances, hence to all rendered XSL
> templates.
>
> Given the case one needs to render XSL template `/a/A.xfo` referring to a
> picture file `./A.png` (hence effectively located at `/a/A.png`), and then
> needs to render XSL template `/b/B.xfo`, referring to a picture file
> `./B.png` (hence effectively found at `/b/B.png`), then there is no other
> solution but to create a new FOP Instance per template: On instance for
> `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively
> results in rather bad performance!
>
> To support this use case while keeping optimal performance (hence: use a
> single FOP factory), there should be a way to pass the baseURI of the
> rendered XSL template to the FOP Factory, so creating a new FOP instances
> effectively use different baseURIs to resolve images. In the past, there had
> been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a
> very bad idea, as concurrent callers ended up in a race condition. So
> reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable
> solution!
>
> Proposed solutions could be to either add an optional parameter baseURI to
> `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method
> `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method
> `FOUserAgent.setBaseURI(baseURI)`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[
https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569870#comment-17569870
]
Markus Karg commented on FOP-3084:
--
BTW, I actually tried your proposed solution and it does not work. I provided a
custom schema as the `baseURI` to FopFactoryBuilder (so the resource builder
understands the prefix to replace by the "dynamic" base URI), while keeping
schema-free relative URIs in the FO file (so the GUI tool is happy), so I could
replace the custom schema by a base URI found in a Thread Var. This might work
for external graphics like PNG, but it does not work for _embedded_ SVG. No
resource resolver is invoked for _embedded_ SVG but instead the custom schema
is forwarded to the SVG handling code by FOP internally, which apparently is
unable to deal with custom schema:
{{java.net.MalformedURLException: unknown protocol: foo}}
{{ at java.base/java.net.URL.(Unknown Source)}}
{{ at java.base/java.net.URL.fromURI(Unknown Source)}}
{{ at java.base/java.net.URI.toURL(Unknown Source)}}
{{ at
org.apache.fop.fo.extensions.svg.SVGElement.getDimension(SVGElement.java:77)}}
Hence the _sole_ +completely+ working solution is to allow either the method
`newFop()` or the user user agent to set a base URI specific for the current
rendering job.
Now as that is proven, can we please go on discussing _how_ we change FOP? :)
> Override baseURI per FOP instance
> -
>
> Key: FOP-3084
> URL: https://issues.apache.org/jira/browse/FOP-3084
> Project: FOP
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Markus Karg
>Priority: Major
>
> There is a best practice to reuse FOP Factory instances for optimal
> performance. But doing so effectively applies the same baseURI (the one used
> at factory creation) to all FOP instances, hence to all rendered XSL
> templates.
>
> Given the case one needs to render XSL template `/a/A.xfo` referring to a
> picture file `./A.png` (hence effectively located at `/a/A.png`), and then
> needs to render XSL template `/b/B.xfo`, referring to a picture file
> `./B.png` (hence effectively found at `/b/B.png`), then there is no other
> solution but to create a new FOP Instance per template: On instance for
> `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively
> results in rather bad performance!
>
> To support this use case while keeping optimal performance (hence: use a
> single FOP factory), there should be a way to pass the baseURI of the
> rendered XSL template to the FOP Factory, so creating a new FOP instances
> effectively use different baseURIs to resolve images. In the past, there had
> been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a
> very bad idea, as concurrent callers ended up in a race condition. So
> reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable
> solution!
>
> Proposed solutions could be to either add an optional parameter baseURI to
> `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method
> `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method
> `FOUserAgent.setBaseURI(baseURI)`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569828#comment-17569828 ] Markus Karg commented on FOP-3084: -- No I cannot. The user must be free to choose the XSL-FO editor of his own choice. The one most of our customer use does not allow to type in arbitrary protocols. Please do not further try to find quirky workarounds. The idea of this issue is to provide a clean and trick-free FOP API. > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569630#comment-17569630 ] Simon Steiner commented on FOP-3084: in the FO you can use your own protocol, xyz://path/my.jpg ? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569623#comment-17569623 ] Markus Karg commented on FOP-3084: -- I tried your workaround, but actually it is not possible because actually the FOP at runtime invokes the `getResource(URI)` method of my custom ResourceResolver with an **absolute** URI apparently built **from the current working directory** and the relative resource URI found in the XSL template. This is pretty strange! So actually there is **not even a workound** for this problem. I only can go with new factories per rendering task, which is really annoying! > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569391#comment-17569391 ] Markus Karg commented on FOP-3084: -- I would rather call that a bad hack but not a sophisticated solution, actually. Hence it might be a possible workaround, but I would not say it is a clean solution for a common use case of a production-grade library. Why not simply proving the URI to the FOP creation methods, as the average coder would expect it to be like? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569388#comment-17569388 ] Simon Steiner commented on FOP-3084: You could get the uri from a threadlocal object? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569369#comment-17569369 ] Markus Karg commented on FOP-3084: -- How should that work in a multithreaded environment? As the same resolver instance is attached with the singleton factory, two concurrent threads would run into a race condition, just as they did with the former `FOPFactory.setBaseURI(baseURI` method. > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FOP-3084) Override baseURI per FOP instance
[ https://issues.apache.org/jira/browse/FOP-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569336#comment-17569336 ] Simon Steiner commented on FOP-3084: cant you implement a custom resource resolver and switch the baseuri used in that? > Override baseURI per FOP instance > - > > Key: FOP-3084 > URL: https://issues.apache.org/jira/browse/FOP-3084 > Project: FOP > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Markus Karg >Priority: Major > > There is a best practice to reuse FOP Factory instances for optimal > performance. But doing so effectively applies the same baseURI (the one used > at factory creation) to all FOP instances, hence to all rendered XSL > templates. > > Given the case one needs to render XSL template `/a/A.xfo` referring to a > picture file `./A.png` (hence effectively located at `/a/A.png`), and then > needs to render XSL template `/b/B.xfo`, referring to a picture file > `./B.png` (hence effectively found at `/b/B.png`), then there is no other > solution but to create a new FOP Instance per template: On instance for > `baseURI=.../a/` and a second instance for `baseURI=.../b/`. This effectively > results in rather bad performance! > > To support this use case while keeping optimal performance (hence: use a > single FOP factory), there should be a way to pass the baseURI of the > rendered XSL template to the FOP Factory, so creating a new FOP instances > effectively use different baseURIs to resolve images. In the past, there had > been a `FOP.setBaseURI(baseURI)` method for this. Clearly that method was a > very bad idea, as concurrent callers ended up in a race condition. So > reintroducing `FOP.setBaseURI(baseURI)` is *definitively not* a viable > solution! > > Proposed solutions could be to either add an optional parameter baseURI to > `FOPFactory.newFOP(..., baseURI)`, _or_ to add a new method > `FOP.setBaseURI(baseURI)` to FOP, _or_ to add a new method > `FOUserAgent.setBaseURI(baseURI)`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
