Thanks for raising that. We’ll investigate on what is happening there and fix.
1 Like
Hey, why is it not possible to do it on the server side? If it’s truly different for every request and it’s not possible or practical to encode the state in the URL then it would seem that a REST API is what’s needed? Could you please describe your use-case?
Hi @mkemp
So far, based on AbstractWebCondition, we took the name of the page from the URL and on this basis we determined in what state a given resource could be loaded in a given context - now, after changing to UrlReadingCondition, these resources do not load correctly 
In the shouldDisplay method we retrieved the URL
SimpleVelocityRequestContext simpleVelocityRequestContext = getSimpleVelocityRequestContext();
String servletUrl = simpleVelocityRequestContext.getRequestParameters().getRequestURL();
...
private SimpleVelocityRequestContext getSimpleVelocityRequestContext(){
Map context = getContextMap(new HashMap<>());
return (SimpleVelocityRequestContext) context.get("requestContext");
}
and then we check if it matches our parameters where we defined the page names
Cheers
Adam
Is this change with new classes for webresource conditions documented somewhere?
Hi,
It looks like REST v2 in latest EAP supports only javax.inject.Inject for resource constructors, and doesn’t support Spring Autowired annotation, is this intentional?
Hey, yes, it is intentional.
We dropped the support for Spring @Autowired annotation and decided to migrate to @Inject (javax.inject.Inject), because @Autowired is spring-specific and javax.inject.Inject is part of a standard (Java EE / Jakarta EE - JSR-330). It’s better to rely on the standard rather than on the specific implementation. It gives us more options in the future.
3 Likes
Hi,
Could we get an update for the List of all breaking changes to the Java and REST APIs (atlassian.com) regarding EAP 05?
1 Like
It sounds like more than just the page name needs to be used? Unless you mean it’s hard to get the page name?
I’ll describe how UrlReading transformers and conditions should work to see if that helps. The addToUrl(UrlBuilder urlBuilder) method is called on every page load, here you should be able to get what ever information you need to determine what to render. Then that information should be encoded by calling urlBuilder#addToQueryString. You’d use something like ExecutingHttpRequest#get() inside this method.
Once the page is loaded, the method shouldDisplay(QueryParams params) should only use the query and/or init parameters to figure out what to render. The result of this will be cached.
Let me know how you go
It lives here atlassian-plugins-webfragment/UPGRADE_700.md
As documented with the new release com.atlassian.plugin.webresource.condition.UrlReadingCondition has been moved to com.atlassian.webresource.spi.condition.UrlReadingCondition. The problem I’m having is that the old-fully qualified name hasn’t been deprecated but has rather been removed, which is making it not possible for us to create a package that supports both Jira 10 and versions of Jira 9 that are still supported.
Is there any guidance on how to write plugins for both Jira 10 and Jira 9 that use UrlReadingCondition or has this been an oversight?
6 Likes
We rely mainly on page names, but we also check the license and whether a given functionality is enabled - but this data is available without any problems
Thanks, I will check it and let you know 
Cheers
Adam
Hi,
I’m getting this JS error in the login page
AG.Gadget.js?locale=en-EG:240 Uncaught TypeError: $ is not a function
at createElement (AG.Gadget.js?locale=en-EG:240:31)
at F.draw (AG.Gadget.js?locale=en-EG:505:13)
at F.init (AG.Gadget.js?locale=en-EG:1018:18)
at AG.Gadget (AG.Gadget.js?locale=en-EG:1100:16)
at Object.addGadget (AG.LayoutManager.js?locale=en-EG:383:29)
at Object.<anonymous> (AG.LayoutManager.js?locale=en-EG:597:26)
at Function.each (jquery.js:370:19)
at appendGadgets (AG.LayoutManager.js?locale=en-EG:596:23)
at Object.init (AG.LayoutManager.js?locale=en-EG:630:21)
at Object.init (AG.LayoutManager.js?locale=en-EG:492:42)
Any idea how to fix it?
Thanks
Our product is bundling OpenSAML. This is working well on older versions of Jira, and on the platform 7 versions of the other DC products. In Jira 10 EAP our plugin won’t instantiate. We get a ServiceLoader error that suggests Jira is now running and exporting OpenSAML in the system bundle:
java.util.ServiceConfigurationError: org.opensaml.core.config.Initializer: Provider org.opensaml.soap.config.impl.XMLObjectProviderInitializer not found
Is this due to embedded crowd or something? I’m trying to understand why this breaks in this EAP.
@MaciejSzarecki, good to know. I checked my app against Velocity method allowlist and found 2 things:
(1) I was surprised that I had to allowlist my actions’s get...() and is...() methods also, because that is not necessary for Confluence 10. I see on https://developer.atlassian.com/server/framework/atlassian-sdk/configuring-the-velocity-allowlist/#auto-allowlisting that this is indeed listed as a Confluence-only feature, but I wonder why this is not also provided for Jira? Doesn’t this sentence from the docu imply that it should be like that:
Ensure any data your Velocity templates require are readily accessible from your Action classes. This will avoid the need to maintain an extensive allowlist.
I would much appreciate it, because then I can get rid of 28 of 66 allowlist-entries which is 42%.
Fyi, also I had to add Jira’s own com.atlassian.jira.web.action.JiraWebActionSupport#isInlineDialogMode(), which is even more confusing.
(2) Please add javax.servlet.http.HttpServletRequestWrapper’s getters to the global allowlist, specifically #getRequestURI(). This is already the case for Confluence 10, for comparison.
In general, I suggest to align Jira10’s global allowlist with Confluence10’s, since Confluence10 already incorporated tons of feedback on that topic and is therefore more complete, see their CDAC-thread.
Hi @AndreasEbert
Thanks for reaching out.
For #2:
Jira has synced the list once with Confluence initially, however, since Confluence has been collecting feedback and running scans for long time, we are about to sync it one more time for common classes like servlets, atlassian core lib methods, web resource package methods. Hopefully, that would help.
Thanks
1 Like
Hi @AndreasEbert, thanks for the information, (1#) yes we’re going to auto-allowlist such methods, no worry 
@MaciejSzarecki, sounds good, thanks. Would be great if you’d announce it here whenever the next EAP is released that includes this. Then I will have another look at my Velocity allowlist and clean it up.
1 Like
@AndreasEbert - Unfortunately, EAP6 will not include these changes - but they will definitely be in 10.0.0 release.
@KarolSkwierawski, well, EAP7 then
1 Like
From the EAP6 the debug mode for velocity method allowlist is disabled. It means that methods will be blocked if not present on the allowlist. If you find any unusual behaviour then look for log like: Invocation blocked as method is not allowlisted: <method>
Based on the JIRA 10 documentation, it is recommended to migrate to REST v2. To achieve this migration, you need to update your code from using Codehaus libraries to FasterXML libraries. This update allows your application to function correctly with JIRA 10.
But JIRA 9 is using Codehaus internally for both deserialization and serialization, is there any way to set JIRA 9 use fasterxml for deserialization and serialization.