Does the
ServiceLoader.load()mechanism work for plugins on P7?
Yep, I tested locally with an external plugin and I’m able to load XContentBuilderExtension using:
for (XContentBuilderExtension service : ServiceLoader.load(XContentBuilderExtension.class))
by specifying elasticsearch as a compile time dependency.
Can you provide more details on how you’ve set this up and/or provide a reproducible example?
Thanks for the confirmation @YingranSun !
I was able to work around the issue by creating XContent builder ‘manually’ and ‘fasttrack’ the conversion with
XContentBuilder builder = JsonXContent.contentBuilder();
qb.toXContent(builder, ToXContent.EMPTY_PARAMS); // qb is the QueryBuilder instance
queryString = BytesReference.bytes(builder).utf8ToString();
FWIW there were some (hidden) elasticsearch / joda-time dependency issues discovered later, and once they were resolved the above approach AND QueryBuilder#toString started to work again. Thank you so much for investigating this!
To run AMPS standalone or atlas-debug with websudo disabled you can run with
-Dfeature.websudo=false
Like so:
atlas-run-standalone --product bitbucket --version 9.0.0-rc7 -Dfeature.websudo=false
We are encountering a strange ‘deadlock’ with Bitbucket 9.0.0-rc7. We are trying to establish a connection to Bamboo via Application link.
That code then hangs here:
"http-nio-7990-exec-3" #47 daemon prio=5 os_prio=0 cpu=5494.00ms elapsed=3040.86s tid=0x00007b0cb29e88f0 nid=0x1e14c in Object.wait() [0x00007b0c83df2000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@17.0.11/Native Method)
- waiting on <no object reference available>
at org.eclipse.gemini.blueprint.service.importer.support.internal.support.RetryTemplate.execute(RetryTemplate.java:104)
- locked <0x00000000d2b9c328> (a java.lang.Object)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor.lookupService(ServiceDynamicInterceptor.java:427)
- locked <0x00000000d2b9c328> (a java.lang.Object)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:400)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:60)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:137)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:70)
at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:53)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.eclipse.gemini.blueprint.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:57)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:137)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:241)
at jdk.proxy10.$Proxy869.createRequest(jdk.proxy10/Unknown Source)
at ch.mibex.stash.cra.loganalysis.CiServers.withAuthenticatedRequest(CiServers.scala:341)
at ch.mibex.stash.cra.loganalysis.CiServers.executeRequest(CiServers.scala:389)
The method which hangs is an invocation of:
com.atlassian.sal.api.net.RequestFactory.createRequest(MethodType.GET, url)
I’ve no good idea yet on how to debug that. Any idea where this could come from?
@RomanStoffel What version of Bamboo are you trying to link to? Are there any warnings/errors in Bitbucket or bamboo application logs? And are you seeing this occur when you try create the applink itself?
What version of Bamboo are you trying to link to?
Bamboo 9.6.4
Are there any warnings/errors in Bitbucket or bamboo application logs?
No logs in Bamboo and Bitbucket side as far as I can tell.
I’ve added and HTTP inspector in front of Bamboo and don’t see any request going out. Which make sense, since the code hangs before we can create the actual request.
And are you seeing this occur when you try create the applink itself?
I don’t understand the question. The applink is configured between Bitbucket and Bamboo. And we try to issue a request for over the app link:
@Bean RequestFactory<Request<?,?> requestFactory = importOsgiService(
RequestFactory.class
)
// Later
ApplicationLink bamboo = ...
var checkAccess = bamboo.getRpcUrl+"/rest/api/1.0/currentUser"
// App link is only used for the URL delibratly, Applink is only convinience for the URL
var req = requestFactory.createRequest(MethodType.GET, url) // Here it hangs!
@RomanStoffel Thanks for those details, I’ll investigate and see if I can reproduce on my end
I don’t understand the question. The applink is configured between Bitbucket and Bamboo.
I wanted to confirm if you were affected by: https://jira.atlassian.com/browse/BSERV-19533 but the version of Bamboo you are using should contain the fix.
I did some more testing. It has nothing to do with the application link. I replaced the URL to another endpoint and it still does hang:
@Bean RequestFactory<Request<?,?> requestFactory = importOsgiService(
com.atlassian.sal.api.net.RequestFactory.class
)
val req = requestFactory.createRequest(MethodType.GET, "https://jsonplaceholder.typicode.com/todos/1") // Here it hangs!
FYI: Release 9.0.0 has the same issue. Just in case.
BB 9 release notes references version 8.19. Is this intentional or perhaps a very rare case of copy and paste error?
Unfortunately that page is cached. If you click the refresh button at the bottom (or clear your cache), you should see the correct version
@RomanStoffel I was able to replicate your issue.
Instead of importing com.atlassian.sal.api.net.RequestFactory.class can you instead import com.atlassian.sal.api.net.MarshallingRequestFactory.class ?
It looks like restv2 no longer exports RequestFactory bean. I’ll see if I can get the documentation updated for that
edit: its documented here: Bitbucket
Hello,
is there something like the WebSudoManager from Confluence for Bitbucket?
Thus, a component to establish a WebSudoSession with Code.
Thanks in advance,
Christopher
Thanks
The MarshallingRequestFactory does work in Bitbucket 9. However, we will use our own embedded HTTP client in the next version. We already had one embedded in the app for other parts of the application. And this way we can support a wider range of Bitbucket versions with a single app.
Yep, you can use WebSudoManager as well for Bitbucket. More details here: https://developer.atlassian.com/server/bitbucket/reference/api-changelog/#secure-administrator-sessions
and
https://developer.atlassian.com/server/framework/atlassian-sdk/adding-websudo-support-to-your-plugin/
thanks for your answer. No, I don’t want to add WebSudo to our UI.
Our app is a SAML SSO app. It allows to use a SAML idp/configuration to establish a WebSudo session when an admin (who is logged in via our app) wants to go to the system settings.
For this, we trigger a re-authentication from the IdP and then establish the WebSudo session via JavaCode.
I found the “BitbucketWebSudoManager” interface, however it looks like the implementation is not exposed. The idea is to call BitbucketWebSudoManager#createWebSudoSession once we got confirmation from the idp.
Bitbucket 9.0.0 got released yesterday:
https://confluence.atlassian.com/bitbucketserver/bitbucket-data-center-9-0-release-notes-1369277827.html
Only for the sake of completeness 
Unfortunately WebSudo is not supported with SSO flows. I’ve raised: https://jira.atlassian.com/browse/BSERV-19537 for this feature request
@UlrichKuhnhardtIzym1 thanks for your feedback. This was fixed.
Hello,
Since upgrading to version 9.0.0, we’ve encountered an issue with the Bitbucket-Crowd SSO integration (specifically Crowd SSO, not SAML) that was working perfectly in version 8.9.0 and earlier.
Here is the relevant stack trace from our error logs:
2024-09-05 14:09:35,493 DEBUG [mesh-sidecar-monitor:thread-2] c.a.s.i.s.g.m.DefaultSidecarManager Sidecar is still alive. Last pong received 2114ms ago.
2024-09-05 14:09:54,820 DEBUG [http-nio-7990-exec-2] @GFC20x849x87x0 127.0.0.1 "POST /rest/analytics/1.0/publish/bulk HTTP/1.1" c.a.b.i.c.sso.SsoConfigurationCache Failed to retrieve SSO configuration
com.atlassian.cache.CacheException: com.atlassian.bitbucket.ServerException: Could not retrieve SSO Configuration (Application failed to authenticate)
at com.atlassian.cache.memory.DelegatingCachedReference.get(DelegatingCachedReference.java:92)
at com.atlassian.cache.impl.metrics.InstrumentedCachedReference.get(InstrumentedCachedReference.java:58)
at com.atlassian.cache.hazelcast.HazelcastAsyncHybridCachedReference.get(HazelcastAsyncHybridCachedReference.java:65)
at com.atlassian.cache.impl.metrics.InstrumentedCachedReference.get(InstrumentedCachedReference.java:58)
at com.atlassian.bitbucket.internal.crowd.sso.SsoConfigurationCache.get(SsoConfigurationCache.java:69)
at com.atlassian.bitbucket.internal.crowd.sso.DefaultCrowdSsoService.getConfiguration(DefaultCrowdSsoService.java:233)
at com.atlassian.bitbucket.internal.crowd.sso.DefaultCrowdSsoService.getAuthenticator(DefaultCrowdSsoService.java:110)
at com.atlassian.bitbucket.internal.crowd.sso.CrowdSsoAuthenticationHandler.performAuthentication(CrowdSsoAuthenticationHandler.java:73)
at com.atlassian.stash.internal.auth.DefaultAuthenticationService.lambda$authenticateInternal$3(DefaultAuthenticationService.java:166)
at com.atlassian.stash.internal.auth.DefaultAuthenticationService.authenticateInternal(DefaultAuthenticationService.java:181)
at com.atlassian.stash.internal.auth.DefaultAuthenticationService.authenticate(DefaultAuthenticationService.java:87)
at jdk.internal.reflect.GeneratedMethodAccessor700.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.proxy3/jdk.proxy3.$Proxy309.authenticate(Unknown Source)
at com.atlassian.stash.internal.spring.security.PluginAuthenticationProvider.authenticate(PluginAuthenticationProvider.java:54)
at jdk.internal.reflect.GeneratedMethodAccessor699.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
I would greatly appreciate any insights or guidance on resolving this. Has anyone else experienced a similar issue or found a workaround?
Thanks in advance!
@Harshitbhagat - Could you please raise a support request at getsupport.atlassian.com?
It’s a secure place for us to gather more information about your specific system/environment.