AOP and pattern design

[moo]

Do you mean?

<T> object = <T> Class.forName&#40;"com.moo.bar"&#41;.newInstance&#40;&#41;

You are correct . That's what I meant, sorry.

So, at this moment I'm not interested in introducing an interface, because I already know what interfaces the loaded object implements. I'm only looking for a possibility to advice the above expression to dynamically replace parameter <T> depending on which interface is requested.

There is no way in Java to dynamically change a cast at runtime. Unless you use code generation or pure reflection you will *always* have to cast to the requied interface at some point.

I know, that`s why I'm looking for an AOP solution.

Can you please send through another explanation of what it is you are trying to do. I don't understand your examples so far.

Ollie

Thanks! I will try to explain what I`m doing right now.
Before I have to apologize for my explanations if they get too verbose.
My english could be better, but I try my best.

Ok, I`m writing a small plug-in container.

The container
The plug-in container is a container with little functionality,
that might be expanded through a set of plug-ins.
So the main purpose of the container is to to manage the lifecycle
(start/stop/...) of the plug-ins and to do the nasty classloader
mechanics. All this will happen dynamically at runtime and I do this with
classworlds, a project at codehaus (http://classworlds.codehaus.org/)

Ok, that`s the container.

Now the plug-in.
Every plug-in consists of one JAR file and some sort of meta information
describing the plug-in`s functionality. This meta file is the
plug-in`s manifest. You might know this concept from the Eclipse project.

Now the plug-in's manifest describes how the plug-in relates to other
plug-ins within the container. This relationship is expressed by so called
"Extension Points" and "Extensions".

Assume you have a plug-in that adds an authorization service to
another plug-in that supports authentication.
To be able to add something you need an "extension point"
that accepts your extension (e.g. the authorization that want to add).

The authentication plug-in makes the extension point available to
the authorization plug-in that delivers the extension.

Back to the sceanrio:
At the time the container loads the authentication plug-in, this plug-in
might "ask" the engine to look for some other plug-in that has the
authorization functionality, i.e. extension. Now the combination of both
plug-ins might make up the login service, that will be controlled by
a third "login" plug-in.

Smallest common divisor
To assure a common point where all plug-ins can "meet",
all of these plug-ins must at least implement one interface
"IPlatformService" that includes two methods:

Class[] getExtensionPoints(); // returns all accepted services, i.e. interfaces

Class[] getExtensions(); // returns all supported services, i.e. interfaces


Now if the authentication plug-in "asks" the container to look out for an
authorization plug-in, then all plug-ins within reach of the container are
asked via call of "Class[] getExtensions();" whether they support the
requested extension for instance "com.moo.foo.auth".
The extension must implement this interface of the requesting caller
(i.e. its extension point). If they do so they are instanciated and
cast to the requested interface.

Because all this is done dynamically, the container cannot predict
what interface might be requested. It depends on the extension point of
the plugin. Therefore you cannot hard code the cast.
But the container can use the information retrieved by calls of
Class[] getExtensionPoints(); or Class[] getExtensions();.

Again, if getExtensionPoints() of some plug-in returns "com.moo.foo.auth"
the container asks all plug-ins by calling getExtensions() if they
support this interface. The container must than cast the loaded and
instanciated suitable object dynamically to the right interface.
Though only the information stated in the manifests of the plug-ins or
retrieved by getExtensions() must suffice, to accomplish this task.


The alternative
Of course, the container may pass objects as a mere "Object" to the
plug-in, delegating the responsability to cast the object to the plug-in
itself, but then the container looses the ability to control the whole
process and indeed the problem is moved out of the container but
not yet solved:
now every plug-in has to impement its own class casting logic.

I hope you now understand why I`m asking for this "autocasting"
feature.

<T> object = <T> Class.forName&#40;"com.moo.bar"&#41;.newInstance&#40;&#41;

Maybe I´m taking the wrong path and this "problem" is much easier to solve. I`ll will be glad to hear if there is a better solution.