We have an app with the with three interfaces per bean. A *BI (business interface) which contains all the methods, a *LI, which extends BI and is annotated as #Local, and *RI, which also extends BI, but is annotated as #Remote.
I want to remove all *LI and *RI interfaces in favor of *BI, leaving they as #Remote, but there is a problem.
Local lookup pass arguments as references, while remote lookup uses deepcopy. The app is full of pass-by-reference expectations (things that only works if pass by reference works).
If I have only #Remote interfaces, the container will know when it is a local lookup and make pass-by-reference works in that case?
Container is JBoss AS 7.1.1 Final and we use EJB 3.1.
Thanks in advance.
Since the local and remote interfaces behave differently even a local client could want to use the remote interface. So it would be a problem if the container just guessed "this client is running in the same VM, let's give him a local interface".
Details on the differences were already discussed here.
If you want to keep all your interface definitions in one place simply write an interface
and let it be inherited by two (empty) interfaces annotated with #Local and #Remote.
Related
I have two different Java 8 projects that will live on different servers and which will both use Akka (specifically Akka Remoting) to talk to each other.
For instance, one app might send a Fizzbuzz message to the other app:
public class Fizzbuzz {
private int foo;
private String bar;
// Getters, setters & ctor omitted for brevity
}
I've never used Akka Remoting before. I assume I need to create a 3rd project, a library/jar for holding the shared messages (such as Fizzbuzz and others) and then pull that library in to both projects as a dependency.
Is it that simple? Are there any serialization (or other Akka and/or networking) considerations that affect the design of these "shared" messages? Thanks in advance!
Shared library is a way to go for sure, except there are indeed serialization concerns:
Akka-remoting docs:
When using remoting for actors you must ensure that the props and messages used for those actors are serializable. Failing to do so will cause the system to behave in an unintended way.
For more information please see Serialization.
Basically, you'll need to provide and configure the serialization for actor props and messages sent (including all the nested classes of course). If I'm not mistaking default settings will get you up and running without any configuration on your side, provided that everything you send over the wire is java-serializable.
However, default config uses default Java serialization, which is known to be quite inefficient - so you might want to switch to protobuf, kryo, or maybe even json. In that case, it would make sense to provide the serialization implementation and bindings as a shared library - either a dedicated one or a part of the "shared models" one that you mentioned in the question - depends if you want to reuse it elsewhere and mind/don't mind having serailization-related transitive dependencies popping all over the place.
Finally, if you allow some personal opinion, I would suggest trying protobuf first - it's binary format (read: efficient) and is widely supported (there are bindings for other languages). Kryo works well too (I have a few closed-source akka-cluster apps with kryo serialization in production), but has a few quirks with regards to collection/map handling.
I am trying to understand and exercise the plugin pattern, as explained by Martin Fowler.
I can understand in which way it makes use of the separated interface pattern, and that it requires a factory to provide the right implementation of the interface, based on the currently used environment (test, prod, dev, etc). But:
How exactly does the factory read the environment values and decide which object (implementing the IdGenerator interface) to create?
Is the factory a dependency of the domain object (DomainObject)?
Thank you very much.
The goal of the Plugin pattern is to provide a centralized configuration runtime to promote modularity and scalability. The criteria that determines which implementation to select can be the environment, or anything else, like account type, user group, etc. The factory is just one way to create the desired plugin instance based on the selection criteria.
Implementation Selection Criteria
How your factory reads the selection criteria (environment state) depends on your implementation. Some common approaches are:
Command-Line Argument, for example, CLI calls from different CI/CD pipeline stages can pass a dev/staging/production argument
YAML Config Files could be deserialized into an object or parsed
Class Annotations to tag each implementation with an environment
Feature Flags, e.g. SaaS like Launch Darkly
Dependency Injection framework like Spring IoC
Product Line Engineering software like Big Lever
REST Endpoint, e.g. http://localhost/test/order can create a test order object without notifying any customers
HTTP Request Parameter, such as a field in the header or body
Dependency on Factory
Since the DomainObject calls the factory to create an object with the desired implementation, the factory will be a dependency of the domain object. That being said, the modern approach is to use a dependency injection (DI) library (Guice, Dagger) or a framework with built-in DI (Spring DI, .Net Core). In these cases, there still is a dependency on the DI library or framework, but not explicitly on any factory class.
Note: The Plugin design pattern described on pp.499-503 of PEAA was written by Rice and Foemmel, not Martin Fowler.
You will want to get a full PFD of the "Patterns of Enterprise Application Architecture". What is visible on Fowler's site is basically first half-page of any chapter :)
What is being describes is basically the expanded version of idea behind polymorphism.
I don't think "plugin" can actually be described as a "pattern". It's more like result of other design choices.
What you have are .. emm ... "packages", where the main class in each of them implements a third party interface. Each of those packages also have their internal dependencies (other classes or even other libraries), which are used for some specific task. Each package has it's of configuration (which might be added through DIC config) ans each of them get "registered" in your main application.
The mentioning of a factory is almost a red herring, because these days that functionality would be applied using DIC.
I wonder if it's possible to get an instance of the JAX-RS Application a resource is attached on. Ideally a way that isn't dependent to a specific implementation. For example using dependency injection...
Thanks very much for your help,
Thierry
As stated in The Spec
5.2.1 Application
The instance of the application-supplied Application subclass can be injected into a class field or method parameter using the #Context annotation. Access to the Application subclass instance allows configuration information to be centralized in that class. Note that this cannot be injected into the Application subclass itself since this would create a circular dependency.
but from I've experienced, it will most likely not be the actual instance, but a proxy. Also if you're looking to alter anything on it, I'm not sure it's possible. It might be read-only.
I'm sorry for editing but I got the feeling like my question was not specific enough.
I have a Host Application, a Interface.dll and a Plugin.dll. Within my Host Application I'm globally using a Instance of a class.
However: My Plugin.dll (which implements my iInterface form the Interface.dll) needs to have access to that specific instance of my class in the Host Application.
By having my Functions names within the interface, I can access those functions in the plugin from the host application, but how can I access the global class instance from the plugin?
I cannot write
Public Interface IPlugin
Sub SetInstance(ByRef MyClassInstance As MyClass)
End Interface
But this es exactly what I want to do...
Thank you very much for your help.
There is no way to implement the class from the host application within an interface. The only way would be referencing as object which will cause plenty of other problems.
Solution was to export the common classes into a own library (.dll) and instantiate this library to both - the host application and the plugin and in the interface.
Now passing the reference is possible without any problems as if all the different code parts were within the same namespace.
Thank you guys for your help.
I have a COM interface GUID but I don't know that interface definition. I don't know what methods it has, what parameters they have and so on. How can I obtain such information? Is it possible in general?
Practical problem is obtaining interface definition for few COM interfaces defined in actxprxy.dll. For example IFileDialogPrivate ({AC92FFC5-F0E9-455A-906B-4A83E74A803B}). (Obviously the interface is not documented and the name does suggest there is a reason for that.) I tried to use OLE/COM Object Viewer (OleView.exe) for that but wasn't able to get the interface definition.
I am trying to implement IFileDialogPrivate while doing some experiments on forcing IExplorerBrowser control to filter Windows 7 library folders. IFileDialog (which seems to use IExplorerBrowser) does it somehow and IExplorerBrowser askes service provider for IFileDialog and IFileDialogPrivate if ICommDlgBrowser is provided so I tryied to explore that interface. (Also it asks for few other interestingly named interface - could be useful).