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 )
