Using Objectify For retrieving from Datastore- Error :Did you forget to inherit required module - google-app-engine

I am using Objectify for retrieving data From datastore in GWT,But i get the Following Error :
[ERROR] No source code is available for type
com.logins.entity.experts; did you forget to inherit a required
module?
I have Client->entity->Server and i did define the RPC properly with RemoteServicePath.
i intiaized the Rpc in client side
final findexpertAsync
finexp=(findexpertAsync)GWT.create(findexpert.class);
GWT compiler throws Error at the method i call,
finexp.expert(expnam, new AsyncCallback<ArrayList<experts>>()
Note:
1) findexpert and FindexpertAsync are the RPC interface which has a method for retriving data from datastore
2)com.logins.entity.experts:experts is a server class.
Any guesses where i am going wrong ?

All classes directly or indirectly referenced from the client must be part of the client source path. You can't access server-only code from GWT. In this case, class "experts" needs to be part of the GWT-compiled client code.
Also: You should capitalize Java class names.

Related

Flink Stateful functions - How to register statefun's ValueSpec in embedded module

I am refactoring my Flink Statefuns for embedded service deployment, but I cannot find the way to register statefun's ValueSpec in EmbeddedModule
When I was using remote http service deployment on k8s, I was building StatefulFunctionSpec with statefun's all value specs inside, and was registering it by StatefulFunctions.withStatefulFunction(spec):
Build static spec in MyStatefun:
static StatefulFunctionSpec SPEC = StatefulFunctionSpec.builder(MY_TYPE)
.withValueSpecs(MY_VALUE_SPEC)
.withSupplier(MyStatefun::new)
.build();
Register it in StatefulFunctions:
StatefulFunctions functions = new StatefulFunctions();
functions.withStatefulFunction(MyStatefun.SPEC);
And finally use functions.requestReplyHandler() as a handler in http server.
What's the way of doing that in EmbeddedModule?
In examples that I found so far, I only see that statefun is registered as this, but does this also register ValueSpecs?
binder.bindFunctionProvider(MyStatefun.FUNCTION_TYPE, x -> (StatefulFunction) new MyStatefun());
UPD. It seems that .bindFunctionProvider(...) cannot bind sdk.java.StatefulFunction, it can only bind sdk.StatefulFunction, which implements .invoke(sdk.Context, Object o) instead of .apply(sdk.java.Context, Message msg). And sdk.Context does not have .storage() method for accessing ValueSpecs.
UPD2. Found page about PersistedValue that could be used for state management and could possibly be the answer to my question: https://nightlies.apache.org/flink/flink-statefun-docs-master/docs/sdk/flink-datastream/

CVE-2021-20289 - migrate from Resteasy jaxrs 3 to RESTEasy > 4.6.0

The vulnerability scan system detects a CVE regarding RestEasy 3.7.0: CVE-2021-20289
https://nvd.nist.gov/vuln/detail/CVE-2021-20289, which states RESTEasy should upgrade to above 4.6.0.Final. But, here comes the question: RESTEasy > 4 does not contains this submodule.
I noticed that in https://developer.jboss.org/en/resteasy/blog/2019/03/28/resteasy-4-is-coming-soon, it is stated that
the big resteasy-jaxrs and resteasy-client modules have been split into resteasy-core-spi, resteasy-client-api, resteasy-core and resteasy-client, with the first and second ones to be considered as public modules, for which we're expected to retain backward compatibility till next major release.
If I comment out the resteasy-jaxrs dependency from pom.xml, I will get error of cannot access class org/jboss/resteasy/microprofile/config/ResteasyConfigFactory. But I cannot find it in resteasy-core-spi or rest-client-api module. The nearest is resteasy-4.7.4.Final/resteasy-core-spi/src/main/java/org/jboss/resteasy/spi/config/ConfigurationFactory.java. But if the class name changed, there would not be easy migration. Or am I missing something?
Actually according to https://issues.redhat.com/browse/RESTEASY-2878, this CVE is fixed in 3.15.2. So I am lost.
At last I
migrate from resteasy 3 to 4, abandon resteasy-jaxrs and introduce resteasy-client-api and resteasy-client
switch from org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder to org.jboss.resteasy.client.jaxrs.internal.ResteasyClientBuilderImpl, even though it's under internal package, it's a public class and Javadoc does not suggest against using it directly. And this implementation is quite standard, and introduces the minimal fraction while migrating. I also compared the default values set in the class, such as connectionPoolSize and so on, they are the same as in resteasy-jaxrs 3.
The code change is minimal:
// before
private ResteasyClient client = new ResteasyClientBuilder()
.connectionPoolSize(CONNECTION_POOL_SIZE)
.build();
// after
private ResteasyClient client = new ResteasyClientBuilderImpl()
.connectionPoolSize(CONNECTION_POOL_SIZE)
.build();
And the provider:
I am receiving content type text/plain. In Resteasy-jaxrs 3, I used ResteasyJackson2Provider and it implements MessageBodyReader and MessageBodyWriter, and it worked. Now, in Restyeasy 4, the content type check seems to be stricter and isReadable() of this same named class only accepts Content-Type of null or contains json. As I receive text/plain, it no longer works.
For reading plain text, I suggest using StringTextStar. A new class in Resteasy 4.7.5, and it seems to work. Reading inputstream and write as string, just what I need. Check its impl.
ResteasyClient client1 = new ResteasyClient()
.register(new ResteasyJackson2Provider()) // for JSON
.build();
ResteasyClient client2 = new ResteasyClient()
.register(new StringTextStar()) // for text/plain
.build();
And the auto-closeable client:
Now you need to use try-finally or try-with-resources to close it. It will be closed automatically if you don't, but you receive a warning: Closing an instance of ApacheHttpClient43Engine for you and so.

Passing a FD to an unnamed pipe over DBus using Vala

I'm trying to send a large block of data between applications by sending a control message over DBus from one to the other requesting a Unix file descriptor. I have it so that the client can request this, the server creates a DBus message that includes a UnixFDList, and the client receives a reply message but it doesn't contain anything. On the server side in Vala the DBusConnection object is setup using register_object, unfortunately the Vapi hides the DBusInterfaceVTable parameter that all the C examples use that would let me specify a delegate for method calls. I've tried to use register_object_with_closures instead but I can't seem to get that to work and the Closure object in Vala is woefully undocumented.
It seems to me that I need one of these methods in order to receive the message from the DBusMethodInvocation object that you get from a call to the DBusInterfaceMethodCallFunc delegate, with that you can create a reply message. Is there a way to either specify a closure class that works with register_object_with_closures, or a way to specify a DBusInterfaceVTable object as part of the service data?
I know that one option is to just create the service in C, but I'd rather figure out and understand how this works in Vala.
Vala uses UnixFDList internally for methods that contain a parameter of type GLib.UnixInputStream, GLib.UnixOutputStream, GLib.Socket, or GLib.FileDescriptorBased.
Example:
[DBus(name="eu.tiliado.Nuvola")]
public interface MasterDbusIfce: GLib.Object {
public abstract void get_connection(
string app_id,
string dbus_id,
out GLib.Socket? socket,
out string? token) throws GLib.Error;
}

Hapi API: how to modify the Message ACK ID behaviour

I am using the following code to generate a message ACK:
public static Message process(Message in) throws Exception {
ADTReceiverQueue.getInstance().submit(in);
Message out = in.generateACK();
return out;
}
}
This generates the following warning:
FileBasedGenerator - Could not write ID to file /var/lib/tomcat7/./id_file, going to use internal ID generator. /var/lib/tomcat7/./id_file (Permission denied)
I can obviously set permissions to remove the warning, however I am wondering how to tell Hapi to use the internal ID generator or possibly a generator where the ID is stored in a database?
HAPI provides the IDGenerator interface to provide different implementations of ID generation. If you look at the JavaDoc for that class you'll find a bunch of different options for doing ID generation and you could certainly roll your own too.
To actually set the ID generator is easy enough, you just need to set it on the ParserConfiguration which is stored in the context.
HapiContext ctx = new DefaultHapiContext();
ctx.getParserConfiguration().setIdGenerator(new FileBasedHiLoGenerator());
If you use that context object to create your server then you're done, or if you didn't you can explicitly set it on the received message before generating an ACK.
in.setParser(ctx.getPipeParser());
-James

Returning JSON from a RESTful service using CXF DOSGI

I have a simple service which is annotated with JAX-RS annotations and includes the #Produces("application/json") annotation. I have set up the following properties when I register the service (I am using DS but that shouldn't matter):
service.exported.interfaces -> *
service.exported.configs -> org.apache.cxf.rs
org.apache.cxf.rs.address -> myURI
When I run my application I can hit the URL, but my browser returns:
No message body writer has been found for response class MyClass.
My OSGi console displays:
Jan 11, 2012 2:29:48 PM org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor writeResponseErrorMessage
WARNING: No message body writer has been found for response class MyClass.
I read the documentation and thought maybe I needed to register a JSON provider. In may Activator I added:
bundleContext.registerService(new String[] { "javax.ws.rs.ext.MessageBodyReader",
"javax.ws.rs.ext.MessageBodyWriter" },
new org.apache.cxf.jaxrs.provider.JSONProvider(), null);
but this has not made any difference.
How do I fix the "No message body writer has been found for response class MyClass." error message?
No message body writer means that your json provider does not understand how to marshal your class that you returned into JSON. If you are using the default JSONProvider, then you are using Jackson, which uses JAXB annotations. In other words, the class that you return should have a #XmlRootElement annotation on the class level.

Resources