BlazeDS - Conversion from ArrayList <BaseClass> on java side to Actionscript - flex3

So we have a java class with two ArrayLists of generics. It looks like
public class Blah
{
public ArrayList<ConcreteClass> a;
public ArrayList<BaseClass> b;
}
by using [ArrayElementType('ConcreteClass')] in the actionscript class, we are able to get all the "a"s converted fine. However with "b", since the actual class coming across the line is a heterogeneous mix of classes like BaseClassImplementation1, BaseClassImplementation2 etc, it gets typed as an object. Is there a way to convert it to the specific concrete class assuming that a strongly typed AS version of the java class exists on the client side
thanks for your help!
Regis

To ensure that all of your DTO classes are marshalled across AS and Java, you need to define each remote class as a "remote class" in AS by using the "RemoteClass" attribute pointing to the java class definition like this [RemoteClass(alias="com.myco.class")].
BlazeDS will perform introspection on the class as it is being serialized/de-serialized and convert it appropriately (see doc below). It doesn't matter how the classes are packed or nested in an array, as long as it can be introspected it should work.
If you need special serialization for a class you can create your own serialization proxys (called beanproxy) by extending "AbastractProxy" and loading them into blazeds using the PropertyProxyRegistry register method on startup.
You will find most of this in the Blaze developers guide http://livedocs.adobe.com/blazeds/1/blazeds_devguide/.
Creating your own beanproxy class look here: //livedocs.adobe.com/blazeds/1/javadoc/flex/messaging/io/BeanProxy.html

Related

Apache Ignite: type substitution on serialization

I have a class A, a cache A_CACHE and a proxy object AProxy extends A. My goal is to serialize AProxy objects as if they are A objects (automatically substitute type) and put them into A_CACHE.
Is there any way in Apache Ignite to substitute type of an object that I am trying to put into cache (serialize using BinarySerializer)?
What I have tried so far.
I have implemented and registered the same BinarySerializer for both types. I have also tried to play with BinaryNameMapper class to return the same class name for both classes, but without success. The only option that comes to my mind now is to use BinaryObjectBuilder. Is it really the only option for me?
After a small research the solution was found.
AProxy should implement writeReplace method of Serializable interface. Return proxied instance from this method. If proxied class is Serializable or Externalizable and one wants to apply custom serialization, than Binarylizable interface should be implemented by proxied class (custom binary serializers are not applied when using the hack above, but instead OptimizedMarshaller is being used).

ByteBuddy - rebase already loaded class

I have the following code working in a SpringBoot application, and it does what's I'm expecting.
TypePool typePool = TypePool.Default.ofClassPath();
ByteBuddyAgent.install();
new ByteBuddy()
.rebase(typePool.describe("com.foo.Bar").resolve(), ClassFileLocator.ForClassLoader.ofClassPath())
.implement(typePool.describe("com.foo.SomeInterface").resolve())
.make()
.load(ClassLoader.getSystemClassLoader());
Its makes is so that the class com.foo.Bar implements the interface com.foo.SomeInterface (which has a default implementation)
I would like to . use the above code by referring to the class as Bar.class, not using the string representation of the name. But if I do that I get the following exception.
java.lang.UnsupportedOperationException: class redefinition failed: attempted to change superclass or interfaces
I believe due to the fact that it cause the class to be loaded, prior to the redefinition. I'm just now learning to use ByteBuddy.
I want to avoid some reflection at runtime, by adding the interface and an implementation using ByteBuddy. I've some other code that checks for this interface.
This is impossible, not because of Byte Buddy but no tool is allowed to do this on a regular VM. (There is the so-called dynamic code evolution VM which is capable of that).
If you want to avoid the problem, use redefine rather then rebase. Whenever you instrument a method, you do now however replace the original.
If this is not acceptable, have a look at the Advice class which you can use by the .visit-API to wrap logic around your original code without replacing it.

difference between class and instance structure

I'm currently trying to learn how to use GObject and there's a point I absolutely don't understand: What's the difference between the class and the instance structure (like "MamanBarClass" and "MamanBar") resp. how do I use them? At the moment I'd put all my object attributes into a private structure (like "MamanBarPrivate"), register it with "g_type_class_add_private" and define properties/getters/setters to access them. But when I leave the class structure empty I get the following error at "g_type_register_static_simple":
specified class size for type `MamanBar' is smaller than `GTypeClass' size
And why are all object methods defined in the class structure (like "GtKWidgetClass")? Probably I'm just screwing up everything, but I only worked with Delphi for OOP yet (I know, nothing to be proud about :D)
Regards
I'm currently trying to learn how to use GObject and there's a point I absolutely don't understand: What's the difference between the class and the instance structure (like "MamanBarClass" and "MamanBar") resp. how do I use them?
The class structure is only created once, and is not instance-specific. It's where you put things which are not instance-specific, such as pointers for virtual methods (which is the most common use for the class struct).
At the moment I'd put all my object attributes into a private structure (like "MamanBarPrivate"), register it with "g_type_class_add_private" and define properties/getters/setters to access them.
Good. That's the right thing to do.
But when I leave the class structure empty I get the following error at "g_type_register_static_simple":
You should never leave the class structure empty. It should always contain the class structure for the type you're inheriting from. For example, if you're trying to create a GObject, the class structure should look like this (at a minimum):
struct _MamanBarClass {
GObjectClass parent_class;
};
Even if you're not inheriting from GObject, you still need the base class for GType:
struct _FooClass {
GTypeClass parent_class;
};
This is how simple inheritance is done in C.
And why are all object methods defined in the class structure (like "GtKWidgetClass")? Probably I'm just screwing up everything, but I only worked with Delphi for OOP yet (I know, nothing to be proud about :D)
Those are virtual public methods. As for why they're defined in the class structure instead of the instance structure, it's because the implementations are the same for every instance.

adapter pattern and dependency

I have little doubt about adapter class. I know what's the goal of adapter class. And when should be used. My doubt is about class construction. I've checked some tutorials and all of them say that I should pass "Adaptee" class as a dependency to my "Adapter".
e.g.
Class SampleAdapter implements MyInterface
{
private AdapteeClass mInstance;
public SampleAdapter(AdapteeClass instance)
{
mInstance=instance;
}
}
This example is copied from wikipedia. As you can see AdapteeClass is passed to my object as dependency. The question is why? If I'm changing interface of an object It's obvious I'm going to use "new" interface and I won't need "old" one. Why I need to create instance of "old" class outside my adapter. Someone may say that I should use dependency injection so I can pass whatever I want, but this is adapter - I need to change interface of concrete class. Personally I think code bellow is better.
Class SampleAdapter implements MyInterface
{
private AdapteeClass mInstance;
public SampleAdapter()
{
mInstance= new AdapteeClass();
}
}
What is your opinion?
I would say that you should always avoid the new operator in a class when it comes to complex objects (except when the class is a Builder or Factory) to reduce coupling and make your code better testable. Off course objects like a List or Dictionary or value objects can be constructed inside a class method (which is probably the purpose of the class method!)
Lets say for example that your AdapteeClass is a Remote Proxy. If you want to use Unit Testing, your unit tests will have to use the real proxy class because there is no way to replace it in your unit tests.
If you use the first approach, you can easily inject a mock or fake into the constructor when running your unit test so you can test all code paths.
Google has a guide on writing testable code which describes this in more detail but some important points are:
Warning Signs for not testable code
new keyword in a constructor or at field declaration
Static method calls in a constructor or at field declaration
Anything more than field assignment in constructors
Object not fully initialized after the constructor finishes (watch out for initialize methods)
Control flow (conditional or looping logic) in a constructor
Code does complex object graph construction inside a constructor rather than using a factory or builder
Adding or using an initialization block
AdapteeClass can have one or more non-trivial constructors. In this case you'll need to duplicate all of them in your SampleAdapter constructor to have the same flexibility. Passing already constructed object is simpler.
I think creating the Adaptee inside the Adapter is limiting. What if some day you want to adapt a pre-existing instance?
To be honest though, I'd do both if at all possible.
Class SampleAdapter implements MyInterface
{
private AdapteeClass mInstance;
public SampleAdapter()
: base (new AdapteeClass())
{
}
public SampleAdapter(AdapteeClass instance)
{
mInstance=instance;
}
}
Let's assume you have an external hard drive with a regular USB port and you are trying to hook it up with a Mac which only has type-c ports. Yes, you can buy a new drive which has a type-c port but what about the data in it?
It's the same for the adapter pattern. There're times you initialize AdapteeClass with tons of flavors. When you do the conversion, you want to keep all the context.

How to decide an object behavior through the web.config?

I want to be able to define in my web.config the type of connexion my object will use to get data (variable) (from an xml or from a databases).
I though about using a Strategie Pattern, but I'm somewhat stuck by the need to write somewhere the name of the class, which I do not want.
Any suggestions?
Additionnal info
I have the interface IContext.
It's implemented in ContextXML and ContextDB.
I have the class Context which has a IContext member (called _context).
The Context class reads (through ContextConfiguration) app.config.
I want _context to be able to be a ContextXML or a ContextDB... or a ContextJSon or any other new class that would implements IContext.
Have you thought about creating a ContextManager class and employing "configuration by convention"?
What I would do, is add a member getName to your IContext interface - this just returns a nice human-readable string for each implementation - as simple as "ContextXML" for your ContextXML class.
When your ContextManager (probably a Singleton, BTW) starts up, it scans a known directory for IContext implementations, instantiating them by reflection (or some other mechanism, I'm not familiar with VB.Net but I'm sure there's a way), and placing them in a collection.
Now when you are building up Context objects, you can ask your ContextManager for a suitable IContext - either explicitly [e.g. getIContextByName("ContextDB")] or with a simpler method that just returns whatever has been configured by some other mechanism - i.e. a suite of methods something like this:
getPossibleIContextImplementationNames()
setCurrentIContextImplementation({name})
getCurrentIContext()
Just as an aside, are you stuck with that naming? Because having a Context object that uses an IContext seems a little unusual. If your IContext implementations are actually used to retrieve data from somewhere, why not call the interface IDAO or IDataAccessor?