Hi @MarekTokarski :-
Looking for your suggestion on the atlassain-rest-v2 changes for Jira 10.x. As we added rest v2 changes, but observed till rest V1 is invoking the classes. Could you please suggest how can we use the rest V2 plugin for Platform 7 changes
Added below changes for rest V2 as per documentation
<rest-migration key="unique-key"> <rest-v2/> </rest-migration>, even this tag no more useful. without this also rest migration is working.
Loaded below dependency from platform-public-api pom , shall we use this or else can we use another pom file for referring the the below Jar file.
<dependency>
<groupId>com.atlassian.plugins.rest</groupId>
<artifactId>atlassian-rest-v2-api</artifactId>
<scope>provided</scope>
</dependency>
Created default constructor for dependency class initilizations. When i debugged the class, till argument constructor which is invoked by v1 , and i could not see the default constructor with V2 log statements. The same is working in confluence plugin app, where as Jira it won't working.
And i could see 2 Jars which are supporting V1 and V2 from this location ~/sde/softwares/atlassian-jira-software-10.0.1-standalone/atlassian-jira/WEB-INF/atlassian-bundled-plugins, and the same jars are reflecting on OSGI page
atlassian-rest-v2-plugin-8.0.6_API.jar. Supports V2
jira-rest-plugin-10.0.1.jar supports v1.
Hi
You are right that rest-migration is obsolete on Platform 7 compatible versions of products.
Using platform-public-api is valid. That POM should be treated as BOM describing all API available for plugins*.
Jira 10 doesn’t contain REST v1. I also double checked and jira-rest-plugin uses REST v2 API and Jakarta REST API 2.0.
Can you elaborate what type of issue are you experiencing. More context and stacktrace would be useful. If I won’t be able to help, I will redirect your question directly to Jira. Issues with initialization may suggest lack of @Inject annotation that is required to properly create REST related elements.
* Please remember that in some cases products may lack the components described there (it is wise to always double check in specific product). Due to the OSGi nature some specific classes defined in Maven dependencies may not be available at runtime.
Hi @MarekTokarski,
As we implemented rest v2 changes in jira , but not sure that which invocation was triggering the call.
Here is the V1 and V2 OSGI bundles, both modules are supported by Jira 10.x
Rest V1 supported OSGI bundle
Rest V2 supported OSGI bundle
I have applied @Inject annotation on my parameter constructor. In addition to this, to support V2 implementation we added default constructor with log statement . But when I started debugging always the 2nd constructor parameterised one is calling. With this behaviour I am not sure V1 or V2 is handling the changes.
Where as Confluence default constructor 1st one is invoking for rest v2. Not sure how to know which implementation was invoking in Jira . Please refer this message to Jira developer team for this use case. In my default constructor logger statement was not printing in jira if V2 is handling the changes.
In Jira 9.x also the 2nd argument is calling always.
Here is my class where invocation happening with 2nd constructor and also had default constructor for handling Rest V2 changes.
Please shed some light on the above query.
Hi @MarekTokarski :-
Can you please update on this post. Appreciate your efforts, if we can send this post to Jira Team to answer my question
I’m sorry, I had to miss previous notification.
Please note that jira-rest-plugin and REST v1 are something different. Jira 10 doesn’t contain REST v1. From what I see jira-rest-plugin is a plugin that uses REST v2 to provide Jira specific REST resources.
I’m not sure what is the issue. First, you don’t need an empty-param constructor to support REST v2. It should inject all beans available in your plugin, as long as you annotated it with @Inject (which I see you did).
I see you mention different versions of Jira and Confluence. I would expect that in all scenarios second, paramterized constructor will be executed. I understand that you had a different behaviour for Confluence. Is that Confluence issue then? What version of Confluence were you testing?
It is hard to provide a meaningful help without full context, but:
- consider removing default constructor
- ensure your plugin doesn’t embed its own copy of
Inject class - that could cause that injection manager may not discover properly your constructor in some cases and then tries to execute default one
