In short: we try to detect annotation, first on method, then on class and finally on package. Based on detected annotation and current user access is allowed or revoked.
I suspect in your case it all boils down to detection issue. Both REST v1 and v2 define their own set of auth annotations. (com.atlassian.plugins.rest.common.security.* vs com.atlassian.plugins.rest.api.security.annotation.*). REST v2 is respecting only its own annotations.
What is more, the type of annotation has to match exactly - in a multi classloader world it means that your plugin has to use the types provided by REST v2 and not some local copy of them.
In Platform 7, REST v2 was enhanced. We support annotations defined in com.atlassian.plugins.rest.api.security.annotation.* but also com.atlassian.annotations.security.*. The second set is preferred. We will remove the original one at some point, but we don’t want to disrupt your migration any more and we don’t have pressure to remove them quickly. What is more on Platform 7 we are detecting not exact types, but only comparing full names of the annotations. That way a plugin can use a different copy of annotations (e.g. local one) and authentication filter will still detect that.
Lastly, AFAIK annotations are resolved quite differently than rest of the code. If your class was compiled with specific annotation and it is missing at runtime, Java will simply ignore it.
I don’t know details of your code, but some actions that you can consider:
remove rest-migration and rely on REST v1 in Confluence 8 - all plugins are automatically attached to REST v2 in Confluence 9, even if migration tag is not present
if plugin is used on Confluence 8 and you want it to use REST v2, then perhaps you could use 2 sets of annotations (from REST v1 and REST v2); you should ensure that your plugin has access to those annotations exported from Confluence - I generally don’t recommend it, but an explicit optional import should do the trick
Please note I didn’t validate the second option on actual instance.
I hope that explanation will give you enough context to resolve your issues!
I’m having these kind of warning messages in Confluence 9:
[confluence.search.v2.FieldMappings] addMapping Mapping for 'content-property-comalaworkflowsglobalmodelversion-version' (DoubleFieldMapping{name='content-property-comalaworkflowsglobalmodelversion-version', stored=false, indexed=true}) conflicts with existing mapping (LongFieldMapping{name='content-property-comalaworkflowsglobalmodelversion-version', stored=false, indexed=true})
This happens with two properties declared in the descriptor within the module content-property-index-schema, one as date and the other one as number.
These properties are not populated in any custom Extractor, just created/updated via JsonContentPropertyService component.
I’m not sure if the ContentPropertyExtractor could be affecting because when this extractor is getting the fields, it is obtaining a StringFieldMapping instead the DateFieldMapping declared in the descriptor. Then, it appears the warn log message, printed by FieldMappings class.
So, am I missing something in the configuration ? Could you make a quick test configuring a content-property-index-schema with a property date type?
I was running into a similar problem recently with mywork-api with Jackson.
We wanted to bundle com.fasterxml.jackson to support 7.19 - 9.0, which then conflicts with mywork-api’s Jackson.
Strangely I never saw the OSGi BundleException logged, only Spring’s UnsatisfiedDependencyException (noting the failed injection of LocalNotificationService).
I even tried using maven-shade-plugin when bundling Jackson, with not much success (albeit with not many attempts either).
Luckily we were only using Jackson once for something rather trivial, which I could replace with some more basic parsing. So I don’t desperately need a solution anymore, but I’m curious if you managed to fix the problem. Thank you!
Hi @AndrewMorton
Have you been able to fix the LocalNotificationService dependency and get an instance of it in the code that runs on Confluence 7.19-8.x?
We got hit hard by
Caused by: java.lang.IllegalArgumentException: org.codehaus.jackson.node.ObjectNode referenced from a method is not visible from class loader
And really a blocker for us to get one binary to support Confluence 7.19+ to 9.x
Cannot remove the Jackson library as it is used by CCMA related code for cloud migration (ObjectMapper thing)
Yes, finally I resolved it, loading dynamically , not injecting it via @ComponentImport annotation. It looks that it has a conflict with Jackson dependencies, so this is the only way I got to make it work with Confluence 8.5.x - 9.
I have a factory, NotificationServiceFactory, that gets the Service of NotificationService extending this class:
public abstract class OptionalService<T> implements DisposableBean {
private final Class<T> type;
private final ServiceTracker tracker;
public OptionalService(final Class<T> type) {
this.type = checkNotNull(type, "type");
final BundleContext bundleContext = FrameworkUtil.getBundle(this.getClass()).getBundleContext();
tracker = new ServiceTracker(bundleContext, type.getName(), null);
tracker.open();
}
/**
* Returns the service (of type {@code T}) if it exists, or {@code null} if not
*
* @return the service (of type {@code T}) if it exists, or {@code null} if not
*/
protected final T getService() {
return type.cast(tracker.getService());
}
@Override
public final void destroy() {
tracker.close();
}
}
This factory has the method that returns the NotificationService:
public NotificationServiceHolder get(){
final NotificationService notificationService = getService();
return new NotificationServiceHolder(notificationService);
}
where the holder has an instance of NotificacionService:
public NotificationServiceHolder(final NotificationService notificationService)
{
this.notificationService = checkNotNull(notificationService, "notificationService");
}
public Object getNotificationService()
{
return notificationService;
}
Finally, you need to declare a component having the notificationServiceHolder where you initialise the notification factory.
It’s very old code when mywork library probably did not exist, this way we checked if the notification service existed or not. So, as we had problems with Jackson dependencies we decided to maintain it.
I have set the system property “confluence.pdfexport.allow.local.hosts=true” on Confluence 9.0.1 Data Center, but the pdf export stylesheet still doesn’t work.
(But it works well on Confluence 8.9 )
Porting from 7.0 to 9.0.3 I have several package that cannot be imported.
When installing my plugin I get these errors:
Package org.apache.commons.lang is internal and is not available for export
Package org.apache.commons.lang.builder is internal and is not available for export
Package org.apache.tools.ant is internal and is not available for export
Package org.apache.tools.ant.types is internal and is not available for export
Package com.google.common.base is internal and is not available for export
Looking at just the first package (org.apache.commons.lang) using dependency:tree its reference by the com.atlassian.confluence:confluence:jar:9.0.3:provided
Is there any plan to adapt atlassian-pocketknife-querydsl dependency for Confluence 9 ??. We are having problems when using it as it has dependencies as fugue, etc.
I’m not familiar with PDF Export feature. Based on your description that endpoint returns image successfully I would expect the issue is not related to REST, but rather to the PDF Export.
I will try to redirect your question to Confluence team. cc: @Kusal .
I am stuck with backwards compatibility for this class com.atlassian.plugin.web.descriptors, which has been moved to com.atlassian.plugin.web.api.descriptors in version 9.x
I have read only a few posts about this with no concrete answers moving forward other than maintaining 2 versions of code - what a crock.
However, I see that some vendors who use Web Sections seem to have been able to provide backward compatibility back to 7.19.x, for the same jar file???
So my question is - How do I make my plugin backward compatible when importing the class WebSectionModuleDescriptor when its class location changes after 9.x?
I don’t use <web-sections>, but one general pattern that may be helpful is to ship two versions of the <web-section> with separate <restriction> tags on each that limit it to the specific version of Confluence that it supports, with each <web-section> targeting a class compiled appropriately. You will likely need to use Maven multi-module projects to accomplish this.
I am getting the following error in Confluence 9.0.3. The app has confluence-create-content-plugin as dependency for the blueprints. Also the app didn’t have any active object entities configured in it.
plugin [{com.my.plugin}] invoking ActiveObjects before configuration module is enabled or plugin is missing an configuration module. Note that scanning of entities from the ao.model package is no longer supported.
