I have a GAE app that uses Google Cloud Storage. On development machine I'm getting following WARNING when trying to use Storage API:
WARNING: Class com.google.appengine.tools.cloudstorage.RetryHelper
loaded from target/webapp-1.0-SNAPSHOT/WEB-INF/lib/appengine-gcs-client-0.3.2.jar
has a dependency on class com.google.appengine.tools.cloudstorage.ExceptionHandler
loaded from (target/webapp-1.0-SNAPSHOT/WEB-INF/lib/appengine-gcs-client-0.3.2.jar <no signer certificates>),
which is not part of App Engine's supported API.
You are strongly discouraged from using this class - your app may
stop working in production at any moment.
What should I do? Does it mean that my version of GCS client is outdated?
I'm using version 0.3.2, it's a latest that I can find in Maven (see). Official site have a different naming scheme, and latest version is r127, but I cannot find this version in Maven.
Is there any other (unofficial?) repo for GCS client library?
I was concerned by the log messages in my development server as well. I looked up the source for ExceptionHandler, and I saw the log message on the latest commit (r120) said:
Remove the use of #AppEngineInternal
as dev appserver complains about it.
Here's a link to it. It seems like the dev server just doesn't like the annotation, and no functionality was changed with the commit.
A fix for this was committed to the library. The fix is what d2013 suggested.
I just tested with version 0.3.3 and can confirm that upgrading the dependency will resolve the issue.
Related
I am using Fabric8 Kubernetes Client library to for Java to create Kubernetes job, but the create method is shown as deprecated. I checked all the available docs and I don't see that its deprecated but IntelliJ IDE is showing as deprecated.
While searching for solution, I found out this link https://github.com/fabric8io/kubernetes-client/issues/3309. I used the same method as defined in the link but IDE still showing it as deprecated.
Here is the screenshot. I am using fabric8 version 6.0.0
Kindly guide me how can I fix this deprecation issue.
Since Fabric8 v6, we've introduced a new resource(T item) DSL method which recieves the resource which is supposed to be operated on. You should be able to access all operations from here.
So, you need to change your code to this:
Job job2 = client.batch().v1().jobs().inNamespace("default").resource(job).create();
You can read more about this in Fabric8 v6 Migration guide.
I am using aws sdk package to access aws api from web application deployed in a websphere application. During build the application doesn't throws any compile time issue. After deployment it throws java.lang.NoSuchFieldError: org/apache/http/conn/ssl/AllowAllHostnameVerifier.INSTANCE
I read some post, it says about jar conflict. Its taking the default httpclient jars from IBM. I want to point my code to take my version of httpclient which I have given in lib folder. Can someone help me to point my code to pick my version of jars added manually.
In order to make your app use its own version of something that's included in the server, you'll need to use parent-last class loader delegation. Assuming the Apache HTTP client is in your web module's WEB-INF/lib directory, you'll want to make that change to the web module's class loader setting (this doc is specifically from 8.5.5 but should work on any version from the last decade or so): https://www.ibm.com/docs/en/was-nd/8.5.5?topic=loading-configuring-web-module-class-loaders
Note that parent-last delegation comes with its own set of risks, as there are some things that don't play well with the server if you try and use a version in your app (the Servlet API is one of the more notable ones). If you try this but run into things like ClassCastExceptions or LinkageErrors, you may instead want to put the HTTP client into an isolated shared library (selecting the "use an isolated class loader for this shared library" option) and associate the shared library with your web module or application: https://www.ibm.com/docs/en/was-nd/8.5.5?topic=servers-managing-shared-libraries
All that said, the simplest solution might just be to update your server. An APAR several years ago (PI50993, included in fixpack 8.5.5.9) removed the application visibility to the server's version of the Apache HTTP client. Moving to a recent fixpack would probably resolve the issue as well.
For a particular functionality implementation, I need to download a chart(even a report would do) from the cognos server from my Java Code. I am unable to find efficient ways of doing the same, I could find few resources(links below) but none of them seem to work. Is there a way to download cognos reports from Java via REST API?
DZONE
MashUp Service
You'll probably want to use the Cognos Mashup Service (CMS). CMS requires a license to use the Cognos SDK.
You didn't specify which version of Cognos, so I can't direct you to the exact documentation.
Our enterprise datawarehouse (EDW) sources data from many interanal & external sources. We use Oracle data integrator (ODI) as teh ETL tool to extract data from the sources. ETL jobs are executed using an ODI agent which is nothing but a Java process. One of the external sources for the warehouse is a webservice. Data is extracted from this webserice using Jython (wrapped within ODI). Jython as you might know is a Python variant which runs within JVM. The Jython job runs under the ODI agent (java) process and extracts data from the webservice.
Coming to the problem we are facing now- The external webservice provider has indicated that soon they will support only TLS 1.2 and will remove support for older TLS connections. The ODI agent is currently on JDK1.6 Update 33 and support TLS 1.1. We are planning to upgrade the ODI agent to Java 7 (which supports TLS 1.2) so that we will be able to connect to this webservice. The Java upgrade involves lot of work mainly to ensure that it does not break existing ETL jobs. If there are any impacts, we might not be able to upgrade. An alternate option is it create a separate Java process (outside of ODI) running under its own JDK (which can be even Java 8) to connect to this web service.
Are there any risks in the above options? It is going to take a while for the provider to give the webservice which supports only TLS 1.2. Are there any public webservices which support only TLS 1.2 that can be used by for our testing? Can you please share them?
Maybe not entirely what you're looking for, but it might be wise to have two seperate development projects for both the old and the future ODI agent to keep things transparent. Especially when testing the new version. It's also advisable to set up a dedicated testing/QA environment for this.
Be sure to keep your production ODI repository safe, you could use a testing repository with some exported projects for this. Maybe this link below might be useful: https://www.redbridgesoftware.com/products/life-cycle-management-for-odi.html
I have a Google AppEngine (Java) project in Eclipse. I want to debug my local code in Eclipse but use the deployed database on AppEngine. Until now I use Remote API with username/password (old way)
This method will be deprecated and I want to use OAuth but when I try to use it, it throws an exception:
java.lang.IllegalStateException: OAuth-based authorization not supported for clients running on App Engine
at com.google.appengine.tools.remoteapi.RemoteApiOptions.getOrCreateHttpTransportForOAuth(RemoteApiOptions.java:359)
at com.google.appengine.tools.remoteapi.RemoteApiOptions.useApplicationDefaultCredential(RemoteApiOptions.java:162)
Everthing is fine when I run a simple Java client app that uses remote api in Eclipse. But if the client is AppEngine development environment in Eclipse, it doesn't work.
How can I debug the server code in eclipse using appengine database?
Bug report: https://code.google.com/p/googleappengine/issues/detail?id=12556
This is expected, as value returned by ApiProxy.getCurrentEnvironment() will not be null, but com.google.appengine.tools.development.LocalHttpRequestEnvironment object. For development server you'll have to use old style (username/password) for now.
According to the documentation, you need to add appengine-remote-api.jar from ${SDK_ROOT}/lib/appengine-remote-api.jar to your WEB-INF/lib directory (or add it to your Maven dependencies) before this will work.
Update: Indeed, it looks like OAuth from App Engine with Remote API has not yet been implemented. I would assume this will change before ClientLogin is fully deprecated, but for now I would recommend opening a feature request on the public issue tracker.
One possible workaround would be to create a regular console application that connects to the Remote API (as per the example in the docs) and can act as a proxy for your App Engine application running on the development server.
In addition to what my colleagues Adam and Nikita previously said, I can officially confirm that the Google Cloud Engineering Team is determined to provide a solution to all reasonable use-cases which are affected by the ClientLogin shutdown before its deadline.
Presumably, the Remote API solution will be available in the upcoming releases 1.9.31/32, although this is just an assumption and there's no ETA for it yet.
As an alternative, you can access Cloud Datastore using Protobufs remotely using service account credentials, which might fit your needs for the moment.
UPDATE 2016/01/21:
The team has extended the ClientLogin shutdown deadline to April 12, 2016.
UPDATE 2016/04/12:
As mentioned before, the fix was properly applied and available in the latest versions of the SDK and gcloud. Remote API can now be used again with OAuth for app-to-app (or devserver-to-app) connection.