Did you try com.atlassian.struts.xsrf.XsrfTokenGenerator?
1 Like
Thank you, looks like that is the one!
I don’t believe we currently publish this as a web page but you can find the JavaDoc JAR here.
Hi,
During our current upgrade testing on the spring-jakarta migration of Crowd (currently on 8.0.0-jakarta-m002) I am unable to find the classes com.atlassian.crowd.model.authentication.UserAuthenticationContext and com.atlassian.crowd.model.authentication.ValidationFactor.
It appears like most of the API in com.atlassian.crowd.model.authentication has been removed. We require the above classes to provide functionality. The interface com.atlassian.crowd.service.client.CrowdClient currently exposes methods that we are unable to call because we cannot obtain the needed classes the API requires as parameters. Is there an equivalent Crowd thread where this feedback can be provided so I can get in touch with the crowd team?
Please import the confluence-plugins-platform-pom to ensure you are using the correct version of the Crowd dependencies. The mentioned classes are still present (in com.atlassian.crowd:crowd-integration-api) and OSGi exported as public API.
1 Like
Hi @Kusal,
I noticed another set of classes that seem to have been removed from embedded Crowd packages. I confirmed that I am using the current confluence-plugins-platform-pom.
I am referring specifically to the classes below. Were they just renamed, or are they deleted? (And if they are gone, can you point us to a functional replacement?)
com.atlassian.crowd.search.EntityDescriptor
com.atlassian.crowd.search.builder.QueryBuilder
com.atlassian.crowd.search.query.entity.GroupQuery
My use case was previously described here.
Thanks!
These classes also continue to remain OSGi available but the com.atlassian.crowd:crowd-api:provided dependency must be explicitly defined now (it was previously included transitively as part of com.atlassian.confluence:confluence).
2 Likes
I’ve upgraded to the latest milestone from 10.0.0-m58 → 10.0.0-m73 . I’m now getting build errors as a few classes that seem to be missing surrounding clusters, I can see they are still included in the java docs for this version. The following are,
import com.atlassian.confluence.event.events.cluster.ClusterEvent
import com.atlassian.confluence.event.events.cluster.ClusterEventWrapper
import com.atlassian.confluence.cluster.ClusterManager
These have also been extracted into the separate artifact com.atlassian.confluence:confluence-cluster-api.
Thank Kusal! That worked, is there any docs on this to find what is being extracted to separate artifacts and where to find them?
Unfortunately I don’t believe we have any formal documentation for which classes are packaged in which artifact right now. You may however be able to navigate from module to module via the parent-child relationships in the POM files of each artifact.
We also don’t expect there to be too many more changes in this regard with the beta release fast approaching, but you are most welcome to continue enquiring here.
1 Like
We used to have:
import com.atlassian.plugin.hostcontainer.HostContainer;
import com.atlassian.plugin.osgi.external.ListableModuleDescriptorFactory;
import com.atlassian.plugin.osgi.external.SingleModuleDescriptorFactory;
import com.atlassian.plugin.spring.scanner.annotation.export.ModuleType;
import org.springframework.beans.factory.annotation.Autowired;
@ModuleType(ListableModuleDescriptorFactory.class)
public class QueueHandlerModuleTypeFactory extends SingleModuleDescriptorFactory<QueueHandlerModuleTypeDescriptor>
{
@Autowired
public QueueHandlerModuleTypeFactory(final HostContainer hostContainer)
{
super(hostContainer, "yogi-queue-handler", QueueHandlerModuleTypeDescriptor.class);
}
}
It tells me the two classes in com.atlassian.plugin.osgi.external are inaccessible. Is there still a way to define module descriptors?
For REST resources, has the injection changed? I’m getting a java.lang.NoSuchMethodException: Could not find a suitable constructor in com.requirementyogi.datacenter.confluenceapp.rest.InfoResource class.
Resolved: Injection-by-constructor still exists, using @jakarta.inject.Inject from jakarta.inject:jakarta.inject-api:2.0.1
Hi @Kusal
did the m85 version bring any changes to ServiceExceptionMapper?
In pom.xml I have
<dependency>
<groupId>com.atlassian.confluence</groupId>
<artifactId>confluence-restv2-server-api</artifactId>
<scope>provided</scope>
</dependency>
but I get an error
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /atlassian-workplace/test_10_extender/exception/RestExceptionMapper.java:[3,54] package com.atlassian.confluence.rest.v2.api.exception does not exist
[ERROR] /atlassian-workplace/test_10_extender/exception/RestExceptionMapper.java:[10,42] cannot find symbol
symbol: class ServiceExceptionMapper
[ERROR] /atlassian-workplace/test_10_extender/exception/RestExceptionMapper.java:[14,5] method does not override or implement a method from a supertype
in previous versions everything worked, maybe the class location changed?, another package?
Cheers
Adam
I’m not aware of any changes to these classes and have confirmed they are still OSGi available. Please also ensure you are using Atlassian Spring Scanner 6.0.0.
We’ve removed this class as it was unused internally but you are welcome to clone that code into your plugin.
Thanks for your quick reply!
I’ve been using this so far due to the application being adapted to “read only” mode - do I understand correctly that since version 10, this instruction https://developer.atlassian.com/server/confluence/how-to-make-your-add-on-compatible-with-read-only-mode/#2-with-an-existing-rest-api-at-the-back-end is no longer valid and we can remove it?
Cheers
Adam
Thanks for pointing this out - in that case it’s possible it was deleted mistakenly as I don’t see this exception handling behaviour configured globally. I’ll follow this up and reinstate the class if appropriate.
1 Like
@Kusal,
Situation: With m85 we don’t have access to com.atlassian.confluence.core.persistence.AnyTypeDao anymore. We use it to fetch PersonalInformation objects from search-results, like so:
for (SearchResult result : results) {
Object pi = anyTypeDao.findByHandle(result.getHandle());
if (pi instanceof PersonalInformation) {
ConfluenceUser user = ((PersonalInformation) pi).getUser();
...
(This is age-old code; ultimately, I think we want to iterate over all (active) users; and once upon a time we decided on this approach – there very well may be a better one)
Question:
Before completely refactoring this code, I’m looking for a simple fix. I came up with this, using ContentEntityManager:
for (SearchResult result : results) {
ContentEntityObject ceo = contentEntityManager.getById(result.getHandleId());
if (ceo instanceof PersonalInformation pi) {
ConfluenceUser user = pi.getUser();
This seems to work fine: It compiles, it installs, it shows expected results in our app.
Any problems you see with this approach?
(Fyi, ContentEntityManager.getById(...) is deprecated, but the mentioned alternative ContentService.find().withId(...).fetch() doesn’t work for us because it doesn’t give us access to the content’s linked user. Happy to give it another shot, with guidance as to how to get the linked user.)
Hey @Kusal
just let you know I have built our plugin successfully with version M85 using AMPS 9.3.3 and 9.3.4, but with the latest version 9.3.5 I get a compilation error
[INFO] Scanning for projects...
[WARNING] The POM for com.atlassian.upm:atlassian-upm-signing-tool:jar:1.0.0 is missing, no dependency information available
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Plugin com.atlassian.maven.plugins:confluence-maven-plugin:9.3.5 or one of its dependencies could not be resolved:
@
[ERROR] Unknown packaging: atlassian-plugin @ line 8, column 16
@
[ERROR] The build could not read 1 project -> [Help 1]
Is it something you already are aware ?
Hi @adam.labus
I’ve confirmed that this was a mistake and that this exception mapper class should still be extended by plugins to leverage the recommended REST error mapping for service exceptions. It will be reinstated in the next EAP. Thanks again for your attentiveness.
No obvious issues, it seems equivalent (although both the previous and current approach don’t seem too performant). We also don’t have any plans to delete that deprecated ContentEntityManager method.
Thanks for reporting this, I’ve passed this on to the appropriate team to rectify.
2 Likes