Is there a Java wrapper for the current version of Stack Overflow? I have been looking at here and here, but they seem to be outdated for current API version. I keep getting connection refused when running their example code. I do have an API key.
StackExchangeApiQueryFactory queryFactory = StackExchangeApiQueryFactory.newInstance("MyApplicationKey");
QuestionApiQuery query = queryFactory.newQuestionApiQuery();
List<Question> questions = query.withSort(Question.SortOrder.HOT).withPaging(new Paging(1, 20)).withTimePeriod(new TimePeriod(new Date(), new Date())).withFetchOptions(EnumSet.of(FilterOption.INCLUDE_BODY, FilterOption.INCLUDE_COMMENTS)).list();
This was an internal proxy mixup. Make sure your proxy is set properly. Also, if you are using an IDE, make sure that Automatic Proxy Configuration is chosen in its settings.
Related
I have a Java azure function (runtime 3.2.0) where I try to send some custom telemetry. I use the following code
TelemetryConfiguration config = TelemetryConfiguration.getActive()
TelemetryClient telemetry = new TelemetryClient(config);
telemetry.trackEvent("Test Event");
telemetry.trackTrace("Test Trace", SeverityLevel.Warning);
telemetry.flush(); // Not sure it is needed
When I check config.getInstrumentationKey() is is the correct key for the Application Insights I want to show the custom telemetry. However, I never receive the custom event and trace in my Insights. Also config.isTrackingDisabled() i false and config.getChannel() seems to make sense.
All code examples I have found and in the official documentation as well it seems to be all the code I need. When I use the logger from the ExecutionContext logs appears in Application inside, so my function has access to it. So I suspect I have overlooked some small important fact or there is some configuration of my function that is not set correctly.
Can anybody help me get custom telemetry to work on my java function?
I'm building a Spring Boot application that's deployed on Google App Engine. To find out the cause of some weird latency issues, I figured I'd enable Google Cloud Trace to view detailed latency reports.
Adding basic tracing was simple enough since this is supported natively by GAE. However, I am having a hard time adding details to any individual trace.
For example; the following code:
public MediaContent getMediaContent(long contentId) {
Optional<MediaContent> found;
try (Scope ss = tracer.spanBuilder("databaseSubSpan").setSampler(Samplers.alwaysSample()).startScopedSpan()) {
tracer.getCurrentSpan().addAnnotation("Retrieving MediaContent " + contentId + " from repository");
found = mediaContentRepository.findById(contentId);
}
if (found.isEmpty()) {
tracer.getCurrentSpan().setStatus(Status.NOT_FOUND);
throw new NoSuchContentException(contentId);
}
return found.get();
}
I figured that in the Cloud Trace UI, this would display a separate little latency line so I could see which part of the total request time is spent on database communication. However, no such information is visible to me:
I have made sure that this exact method is invoked by adding a few log entries around it. All the log entries (even the one inside the try block) show up in my logs.
I set the sampling rate to 100% by adding the following to my application.yml: spring.sleuth.sampler.probability: 1.0
Basically, what I expected to see on the Cloud Trace UI is a second bar underneath the primary request. As such:
Is this even possible in Cloud Trace? I expect that it would be since the chart is so tall which seems to me like it has space left for extra bars. If it is, what am I doing wrong?
Thanks.
It needs to be investigated by the Google product team.
Then I would suggest forwarding this through a Public Issue Tracker for further support. or you can open a ticket with Google Cloud support (For free users this link) so that we may investigate this issue further.
I used StartApplicationRequest to create a sample request to start the application as given below:
StartApplicationRequest request = StartApplicationRequest.builder()
.applicationId("test-app-name")
.build();
Then, I used the ReactorCloudFoundryClient to start the application as shown below:
cloudFoundryClient.applicationsV3().start(request);
But my test application test-app-name is not getting started. I'm using latest Java CF client version (v4.5.0 RELEASE), but not seeing a way around to start the application.
Quite surprisingly, the outdated version seems to be working with the below code:
cfstatus = cfClient.startApplication("test-app-name"); //start app
cfstatus = cfClient.stopApplication("test-app-name"); //stop app
cfstatus = cfClient.restartApplication("test-app-name"); //stop app
I want to do the same with latest CF client library, but I don't see any useful reference. I referred to test cases written at CloudFoundry official Github repo. I derived to the below code after checking out a lot of docs:
StartApplicationRequest request = StartApplicationRequest.builder()
.applicationId("test-app-name")
.build();
cloudFoundryClient.applicationsV3().start(request);
Note that cloudFoundryClient is ReactorCloudFoundryClient instance as the latest library doesn't support the client class used with outdated code. I would like to do all operations (start/stop/restart) with latest library. The above code isn't working.
A couple things here...
Using the reactor based client, your call to cloudFoundryClient.applicationsV3().start(request) returns a Mono<StartApplicationResponse>. That's not the actual response, it's the possibility of one. You need to do something to get the response. See here for more details.
If you would like similar behavior to the original cf-java-client, you can call .block() on the Mono<StartApplicationResponse> and it will wait and turn into a response.
Ex:
client.applicationsV3()
.start(StartApplicationRequest.builder()
.applicationId("test-app-name")
.build())
.block()
The second thing is that it's .applicationId not applicationName. You need to pass in an application guid, not the name. As it is, you're going to get a 404 saying the application doesn't exist. You can use the client to fetch the guid, or you can use CloudFoundryOperations instead (see #3).
The CloudFoundryOperations interface is a higher-level API. It's easier to use, in general, and supports things like starting an app based on the name instead of the guid.
Ex:
ops.applications()
.start(StartApplicationRequest.builder()
.name("test-app-name").build())
.block();
I'm (new at this) developing a macro plugin that builds on data that an existing plugin provides via its REST API. They would run on the same instance of Confluence, version 5.9.
I cannot use the Java API of the plugin, since it only provides access to a very limited amount of classes, so I decided on using Rest.
Given that the user has already authenticated with Confluence, is there any way to communicate my current user credentials from my plugins Java Rest client to the other one, preferably not using Basic Authentication?
So far, I've tried:
Shared Access Layer - this apparently used to work with the method Request#addTrustedTokenAuthentication() but is deprecated in SAL 3.0.5,
see SAL Documentation (outdated?), and SAL Version Matrix
ApplicationLink - would allow me to link to another application, but apparently it's not possible to link back to the same Confluence instance
SAL TrustedRequestFactory- comments on this atlassian answer indicate there might be a way using this, but I can't seem to figure it out (yet).
I've also tried reading up on atlassian documentation and posted a similar question on atlassian answers here. I don't mean to double post, but unfortunately, looking at other questions on that platform, few seem to get answered in a timely fashion so I thought I'd try my luck here.
Seems like this isn't a very common problem, but I thought I'd post how we eventually solved this, just in case it's needed again:
#Component
public class RestClient {
#ComponentImport
private TrustedTokenFactory tokenFactory;
// [...]
public String doRequest(HttpClient client, String url) throws Exception {
TrustedTokenAuthenticator auth =
new TrustedTokenAuthenticator(tokenFactory);
HttpMethod method = auth.makeMethod(client, url);
try {
// add request headers, etc...
int statusCode = client.executeMethod(method);
// be sure to use response data here, catch exceptions...
} finally {
method.releaseConnection();
}
}
}
I'm using SparkJava 2.2 which is using Jetty 9.0.2.
I'm getting "Form too large" exception which is thrown by Jetty. I already know how to solve this problem if I was using Jetty directly:
Form too Large Exception
http://www.eclipse.org/jetty/documentation/current/setting-form-size.html
PROBLEM :
Now I need to find a way to change org.eclipse.jetty.server.Request.maxFormContentSize setting through SparkJava. Is there a way to do this?
I must note that other methods (JVM_OPTS, System.setProperty) do not work for me for some reason. I'm still getting the same exception.
Stacktrace:
[qtp1858644635-27] ERROR spark.webserver.MatcherFilter -
java.lang.IllegalStateException: Form too large 308913>200000
at org.eclipse.jetty.server.Request.extractParameters(Request.java:334)
at org.eclipse.jetty.server.Request.getParameterMap(Request.java:765)
at javax.servlet.ServletRequestWrapper.getParameterMap(ServletRequestWrapper.java:193)
at spark.QueryParamsMap.<init>(QueryParamsMap.java:59)
at spark.Request.initQueryMap(Request.java:364)
at spark.Request.queryMap(Request.java:349)
at spark.webserver.RequestWrapper.queryMap(RequestWrapper.java:213)
at com.xyz.analytics.webservice.RequestTools.getRequestQueryMap(RequestTools.java:27)
at com.xyz.analytics.webservice.RequestTools.getMandrillQueryParams(RequestTools.java:22)
at com.xyz.analytics.webservice.Endpoints.lambda$initiateEndpointsAndExceptionHandlers$2(Endpoints.java:61)
at com.xyz.analytics.webservice.Endpoints$$Lambda$3/1485697819.handle(Unknown Source)
at spark.SparkBase$1.handle(SparkBase.java:311)
at spark.webserver.MatcherFilter.doFilter(MatcherFilter.java:159)
at spark.webserver.JettyHandler.doHandle(JettyHandler.java:60)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:179)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:451)
at org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:252)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:266)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:240)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
at java.lang.Thread.run(Thread.java:745)
Edit:
I must note that other methods (JVM_OPTS, System.setProperty) do not work for me.
Well, debugger doesn't even stop at any breakpoint set within org.eclipse.jetty.server.handlerContextHandler... Plus when it stops at org.eclipse.jetty.server.Request breakpoints, _context property is null. Seems that SparkJava is handling it differently. Dead end.
Request does one more thing before setting maxFormContentSize = 200000;. It checks _channel.getServer().getAttribute("org.eclipse.jetty.server.Request.maxFormContentSize").
Except Server's attribute collection is empty... And I don't see any way to add any attribute. Jetty Server is created by SparkBase.init() which calls SparkServer.ignite().
But it doesn't help us much. It's not easy to "break in" to make our own adjustments. It seems pretty hopeless.
Not possible with Spark 2.2
The creation of the ServerConnector is hardcoded in the SparkServer, you cannot change those values after the fact, they have to be passed into the ServerConnector before server start.
Would recommend filing a bug with Spark to make that configurable.
https://github.com/perwendel/spark/issues
Good news everyone :)
In Spark 2.6 (released April 2017) embedded Jetty is fully configurable!
Release notes: http://sparkjava.com/news#spark-26-released
See the original future request for more details here: https://github.com/perwendel/spark/issues/314
and related pull request here:
https://github.com/perwendel/spark/pull/813
NOTE that it is also possible to run Spark on another web server instead of the embedded Jetty server:
http://sparkjava.com/documentation#other-web-server
Well, having access to the server object, you can always do something like:
server.setAttribute("org.eclipse.jetty.server.Request.maxFormContentSize", 1024 * 1024);
Hope this helps!