accessing a static property via COM - delphi

is it possible to access a static property of a COM object without creating an instance of the object?
my situation is this:
i have an unmanaged application (written in delphi). this application exposes a COM-based plugininterface. until now i only wrote managed plugins in c#. plugins provide their info (name, author, ..) via a static property that returns an instance of PluginInfo (which implements IPluginInfo). this static property i can access on the managed plugins using http://managedvcl.com.
now i want to write unmanaged plugins on the same interface. i can load them using:
plug := CreateComObject(TGuid) as IMyPlugInterface;
and they run, but i don't know how to read out their PluginInfo.
so the question again is: is there another way than implementing IPluginInfo in the plugin-class and only accessing the info after i have created an instance of the plugin?

It may not be as "elegant" as the static property provided by the C# plug-in architectures you are used to, but you could provide an exported function in the COM DLL that returns an IPluginInfo. By convention this exported function would have the same name in every plug-in DLL designed to operate in your architecture.
The host application would obtain the proc address for the exported function dynamically at runtime then call it to obtain the IPluginInfo interfaced object for that specific plug-in DLL. The mechanics for this could all be encapsulated in a class for your plug-in architecture, hiding the implementation details.
It would take very little work to reach a point where your plug-in architecture would be just as convenient to use and code against as the C# infrastructure you are more used to.

No. Delphi's interfaces are implemented as virtual methods (basically) on an object instance, and AFAIK can't accept static members. That would probably make a useful enhancement, though.

Related

Does Microsoft DependencyInjection support non-constructor injection?

I am trying to incorporate Microsoft.Extensions.DependencyInjection into an existing ASP.NET 4.6.1 app.
I know that while .NET Core has it built-in, for 4.6.1 you need to create some initial classes as outlined in http://scottdorman.github.io/2016/03/17/integrating-asp.net-core-dependency-injection-in-mvc-4/. (The article seems to be out of date since the sample code does not show implementation of BeginScope() and Dispose() for IDependencyResolver. If anybody has more updated examples that would be appreciated.)
"Services" accessed by controllers where you are creating instances via constructors is fairly simple but my problem is when I need an instance of "something" that is from a property or method of an existing object.
For example, I have a inherited DbContext that needs an instance of System.Security.Principal.IIdentity that comes from the logged in user.
Another example is an instance of ApplicationUser. ApplicationUser inherits IdentityUser and the current user can be found by calling FindById() method of AppUserManager.
While AppUserManager can easily be instantiated using DI, how can I use DI the inject the output of the FindById() method? I cannot seem to find any documentation or sample code about this for Microsoft based framework. Other frameworks like Unity seem to support Property-based injection.
In essence, can DI be used with all existing classes or do you specifically need to code out the classes to support DI from the beginning? (i.e. only expect parameters to be passed in via constructors and make sure those instances themselves are created via constructors).
The very simple and short answer to your question "Does Microsoft DependencyInjection support non-constructor injection?" is, no.
Out-the-box Microsoft DI does not currently support property injection like other frameworks such as Ninject. If you need that feature, I suggest using those frameworks instead (I cant imagine MS has any plans to add property injection any time soon).
Your other option is to consider how you can refactor your code to use constructor injection instead which is the preferred method

Dart when to use the mirror API

This may be a silly question, so sorry for asking this, and fyi I'm new to this kind of stuff.
After reading the documentation about mirrors, I can only grasp that the mirrors API is just like copying some instance plus access to some method that I don't know when/why to use.
Anybody care to give me some pointers, some example would be nice.
Mirror API allows you to retrieve metadata about objects and types programmatically (during execution) and to execute methods on objects . It is similar to reflection in .NET or Java.
A typical example is implementing plugin support:
Let's say that you define an IPlugin interface and want to automatically register with your PluginManager an instance of each type that implements it, without need to explicitly register each new implementation. Sometimes you even don't know all the plugins in advance, e.g. if users can deploy their own plugins.
You could do it like this (WARNING: I have never used Mirror API, so this is a high level description based on API documentation, not a proper implementation):
You first use MirrorSystem.libraries to get LibraryMirror instance for each library in that MirrorSystem
Then for each LibraryMirror you use classes property to get ClassMirror for each class in the library
For each ClassMirror use superinterfaces to get all implemented interfaces
If any of the implemented interfaces is IPlugin you can create an instance of that class (ClassMirror.newInstance) and register it with plugin manager.
Without mirror API, you would not be able to enumerate all the types, find what interfaces they implement (without creating an object) or create an instance of a type that you don't know about in advance.
To be honest I am not sure what is the current state of mirror API in Dart, I believe that it is still not finished, but I might be wrong.

Is there a Delphi equivalent to Java's PermissionManager or AccessController classes?

Are there any classes (free, open source or commercial) that perform access control similar to what Java's AccessController does? I want to create a dynamic set of policies that can be changed at runtime.
But, I want to avoid having to code
if Allowed( ... ) then
all over the place. I know that I probably need to adjust my program class hierarchy, but I prefer that instead of manually adding guards all over the place.
If there are is no ready-to-use code, what would be a sensible approach? RTTI?
Edit: Here's an example from the Security Annotations and Authorization in GlassFish and the Java EE 5 SDK article. Since somebody mentioned annotations in a comment, I think this would be ideal:
#Stateless
#RolesAllowed("javaee")
public class HelloEJB implements Hello {
#PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
From the article:
In this example, the hello() method is accessible by everyone, and the bye() method is accessible by users of role javaee.
Edit:
Well, it appears that the general consensus is that this can't be done in Delphi. Others think it is a bad approach.
Me, I still think this would be great. My experience with Annotations in Java (as a code monkey way down in the totem pole) is positive. You add a new method, you add some form of annotation (not exactly the same as Java Security Annotations) and you are done. An administrator can later go to the admin panel and add grant access to this new handler to a group or individual users. It just works.
These are my current alternatives:
The TMS Security System - this appears like a complete solution, with several tools. Worth looking into. I'm accepting this as an answer even if I'm probably not going for it.
This is something that looks promising: Delphi virtual method interception. It only works on virtual methods, but I don't think that's too difficult to comply. This and annotations could make an interesting system (it appears that this was originally designed for DataSnap authentication)
Having only one ActionManager in your application, and make sure that all actions can be only initiated from there. This way you can use the action manager OnExecute method; I pretend to use the TAction.Name property as the permission name ("handler"), reading a list of allowed actions from a table. I can use the action list from the action manager to display the whole list in the admin UI.
There is no such framework for Delphi yet, nor a concept like EJBs that would fit with it. DELPHI does support class annotations, and a framework like this could be designed, perhaps in conjunction with TAction, to provide security on an action level, but I doubt that this could be extended to blocking specific method calls. Delphi code does not ever ask permission to invoke a virtual method. Anything that injected itself into EVERY virtual method call in Delphi, adding a checkPermission call behind the scenes would (in my opinion) be evil. It would be Slow, and worse than writing such checks in by hand.
However, the same techniques that are used to Mock delphi classes could perhaps be used to create some auto-security wrapper object in the future.
I am guessing that the if the Java library in question used Aspects (essentially "injection" implemented via a technique like code-hooking) then it would not require "CheckAllowed" calls everywhere. If you didn't mind changing all your method invocations to implementing an interface, and then providing a wrapper that did the method invocations, and used some kind of auto-generated mock-security-wrapper around it, you could avoid calls to CheckAllowed.
So a guarded No, with a "limited framework possible in future" clause.
Yes, there is a Delphi Access Control Library (lkacl) (OpenSource), JCL (OpenSource) which offers a pretty comprehensive security features, and finally if your demands would be really high the most popular commercial solution is TMS Security System.

In Blackberry, how are shared objects in runtimestore recognized by other applications

In Blackberry Runtime Store, when sharing objects between applications. How can we call methods of the shared object in another application, if the object itself is not recognized in the other application ? i am getting a runtime error when object gets typecasted, as that object is not defined in the calling applicatoin .
If i typecast it to super interface and have the interface in another application. When i call getClass() on the object returned from the runtimestore. It shows as concrete class instance stored in the RunTimeStore.
How can a share a object in runtimestore and use it across different applications ?
The referenced question seems to answer what you're asking.
If you're putting com.foo.bar.MyClass which implements the com.foo.bar.MyInterface in app1, you need to also have it in app2. The package that your class and interface appears to make a difference.
How is your question different?
You seem to have answered your own question - you can typecast to an interface that the calling app is aware of. If you want to cast to a class/interface that's not defined in the calling app though, you're out of luck - it can't be done.
BlackBerry is based on Java ME (formerly J2ME) which has very limited support for runtime reflection - essentially just class names, which you're already seeing when you get the name of the class from the Runtime Store. Unlike Java SE/EE you can't call methods on classes using the String names of the methods - it would be very handy to have sometimes, but unfortunately not supported.
So to summarize, if you can't include the class definition in your calling app, derive an interface (or superclass) with the methods the calling app wants to call, make the class implement that interface, and include that interface/superclass in both the calling app and the other app.

Can Structuremap DefaultConventionScanner find non-public classes

I have just started using StructureMap, having previously worked with Spring.Net. I love the DefaultConventionScanner and the ability to scan assemblies and use convention over configuration to find classes. But there seems to be a limitation that the classes that implement the interfaces must be public, whereas we like to keep out interfaces public and our implementations internal to an assembly.
Is there a way to ask the DefaultConventionScanner to find internal classes as well?
No, and in fact the limitation that classes should be public applies to all of StructureMap - not just the convention scanners. You can register internal types manually with StructureMap if you make use of the InternalsVisibleTo attribute, but it is not well-supported or documented. You will not be able to make an ITypeScanner (like DefaultConventionScanner) that registers internal types because the AssemblyScanner only exposes exported types.

Resources