Java Reflection: Call abstract interface methods without instantiation - java

I am currently facing problems integrating the existing Piketec TPT Java API (http://javadoc.jenkins.io/plugin/piketec-tpt/com/piketec/tpt/api/package-summary.html) in a Java project by using Reflection.
The TPT Api provides an interface called "TptApi", which contains several abstract methods, that are used to access TPT projects.
I have already integrated other APIs such as the Dox4j-API, where a class instance was used as invokation target. Obvisouly, this is not the correct way for accessing method from an interface.
My goal is to access the method "OpenResult openProject(File f)" from the TptApi interface (http://javadoc.jenkins.io/plugin/piketec-tpt/com/piketec/tpt/api/TptApi.html#openProject-java.io.File-).
My code:
ClassLoader cl = new URLClassLoader(...);
Map c = new HashMap();
File file = new File("test.prj");
c.put("TptApi", cl.loadClass("com.piketec.tpt.api.TptApi"));
c.put("OpenResult", cl.loadClass("com.piketec.tpt.api.OpenResult"));
//The way I did it with 'normal' classes, not applicable with the interface:
//Object target = ((Class) c.get("TptApi")).newInstance();
OpenResult or = (OpenResult)((Class) c.get("TptApi")).getMethod("openProject", new Class[]{File.class}).invoke(target, new Object[]{_file});
So how do I access abstract interface methods by Reflection?

I just stumbled over this Question so let me answer it even if it is a bit outdated. I read in your comments that you assume you do not need the TPT tool itselfe to use the API. That is simply wrong. The API is just a way to communicate via RMI with an open TPT instance. To connect to TPT the TPT instance must have enabled RMI and you have to know the configurable port and binding name. You can do that in the Preferences under "TPT API" or by starting TPT with command line arguments "--apiPort " and "--apiBindingName ". Now you can obtain the TptApi instance using these two lines of code:
Registry registry = LocateRegistry.getRegistry(HOST, PORT); // get Server/RMI-Registry
TptApi remoteApi = (TptApi)registry.lookup(BINDING_NAME); // get TPT-API

My initial post did not assume that TPT is not necessary for the usage of the API. It indeed is. The way how to enable the API in TPT is well-documented, the two lines of code you posted are also ok. The problem I described is to access the API by using Java reflection. For other APIs I could do this by using "newInstance" to get access to the tool. With TPT, the corresponding API object is an interface instead of a class, so there is no way to instantiate it. Therefore I wanted to know how this specific API can be accessed via reflection.

Related

How to subclass SubethaSmtp SMTPClient class

I am trying to develop a simple SMTPclient for testing purposes using the SubethaSmtp client package. i want to use the SMTPClient class instead of the SmartClient class for more control but i have not been able to figure out how to write mail data using SMTPClient, the only OutputStream exposed to public or external subclasses is the one for sending commands, the ones for sending data (after sending the DATA command) is exposed only to classes in the same package (SmartClient).
am i missing something here? i would like to know how a direct subclass of SMARTClient can written to work around this problem.
Looks like you are correct, you cannot simply extend the SMTPClient and get access similar to the one that SmartClient has, being a same-package class.
At this point you can either:
1) Fork your own version of the app from https://github.com/voodoodyne/subethasmtp and do whatever the hell you like with it, or
2) Go all the way and implement your own version of SMTPClient, as the package protected SMTPClient.dotTerminatedOutput;, used by SmartClient.dataWrite() actually is just instantiated like so
...
this.rawOutput = this.socket.getOutputStream();
this.dotTerminatedOutput = new DotTerminatedOutputStream(this.rawOutput);
...

Rhapsody java api

I'm trying to use Java api of Rhapsody. When I looked at the tutorial of the api, there is lots of different irp interfaces, also sometimes they have the same operations.. I could'nt make concrete. For example, I'm trying to reach interface package.
I wrote the following code segment.
IRPApplication rpy=null;
IRPModelElement ele =null;
rpy= RhapsodyAppServer.getActiveRhapsodyApplication();
How can I reach the interfaces in Interface package and the operations in one interface class?
This should help (there's a sample project at the end of the article)
Rhapsody Helpers
IRPProject project = rpy.activeProject();
IRPModelElement thatInterface = project.findNestedElementRecursive("[interface name]", "Interface");
if the interface is at the top level, you don't need Recursive, but it's not a bad idea to leave it in either way.
This is how you can find a package that contains the interface
IRPModelElement interfacePackage = project.findNestedElement("[package name]", "Package");
This is how you can find the interface in that package
IRPClass m_interface = (IRPClass)interfacePackage.findNestedElement(interfaceName, "Interface");

How to dynamically differentiate the memcahce instances in java code?

Can anyone suggest any design pattern to dynamically differentiate the memcahce instances in java code?
Previously in my application there is only one memcache instance configured this way
Step-1:
dev.memcached.location=33.10.77.88:11211
dev.memcached.poolsize=5
Step-2:
Then i am accessing that memcache in code as follows,
private MemcachedInterface() throws IOException {
String location =stringParam("memcached.location", "33.10.77.88:11211");
MemcachedClientBuilder builder = new XMemcachedClientBuilder(AddrUtil.getAddresses(location));
}
Then i am invoking that memcache as follows in code using above MemcachedInterface(),
Step-3:
MemcachedInterface.getSoleInstance();
And then i am using that MemcachedInterface() to get/set data as follows,
MemcachedInterface.set(MEMCACHED_CUSTS, "{}");
resp = MemcachedInterface.gets(MEMCACHED_CUSTS);
My question is if i introduce an new memcache instance in our architechture,configuration is done as follows,
Step-1:
dev.memcached.location=33.10.77.89:11211
dev.memcached.poolsize=5
So, first memcache instance is in 33.10.77.88:11211 and second memcache instance is in 33.10.77.89:11211
until this its ok...but....
how to handle Step-2 and Step-3 in this case,To get the MemcachedInterface dynamically.
1)should i use one more interface called MemcachedInterface2() in step-2
Now the actual problem comes in,
I am having 4 webservers in my application.Previoulsy all are writing to MemcachedInterface(),but now as i will introduce one more memcache instance ex:MemcachedInterface2() ws1 and ws2 should write in MemcachedInterface() and ws3 and ws4 should write in ex:MemcachedInterface2()
So,if i use one more interface called MemcachedInterface2() as mentioned above,
This an code burden as i should change all the classes using WS3 and WS4 to Ex:MemcachedInterface2() .
Can anyone suggest one approach with limited code changes??
xmemcached supports constistent hashing which will allow your client to choose the right memcached server instance from the pool. You can refer to this answer for a bit more detail Do client need to worry about multiple memcache servers?
So, if I understood correctly, you'll have to
use only one memcached client in all your webapps
since you have your own wrapper class around the memcached client MemcachedInterface, you'll have to add some method to this interface, that enables to add/remove server to an existing client. See the user guide (scroll down a little): https://code.google.com/p/xmemcached/wiki/User_Guide#JMX_Support
as far as i can see is, you have duplicate code running on different machines as like parallel web services. thus, i recommend this to differentiate each;
Use Singleton Facade service for wrapping your memcached client. (I think you are already doing this)
Use Encapsulation. Encapsulate your memcached client for de-couple from your code. interface L2Cache
For each server, give them a name in global variable. Assign those values via JVM or your own configuration files via jar or whatever. JVM: --Dcom.projectname.servername=server-1
Use this global variable as a parameter, configure your Service getInstance method.
public static L2Cache getCache() {
if (System.getProperty("com.projectname.servername").equals("server-1"))
return new L2CacheImpl(SERVER_1_L2_REACHIBILITY_ADDRESSES, POOL_SIZE);
}
good luck with your design!
You should list all memcached server instances as space separated in your config.
e.g.
33.10.77.88:11211 33.10.77.89:11211
So, in your code (Step2):
private MemcachedInterface() throws IOException
{
String location =stringParam("memcached.location", "33.10.77.88:11211 33.10.77.89:11211");
MemcachedClientBuilder builder = new XMemcachedClientBuilder(AddrUtil.getAddresses(location));
}
Then in Step3 you don't need to change anything...e.g. MemcachedInterface.getSoleInstance(); .
You can read more in memcached tutorial article:
Use Memcached for Java enterprise performance, Part 1: Architecture and setup
http://www.javaworld.com/javaworld/jw-04-2012/120418-memcached-for-java-enterprise-performance.html
Use Memcached for Java enterprise performance, Part 2: Database-driven web apps
http://www.javaworld.com/javaworld/jw-05-2012/120515-memcached-for-java-enterprise-performance-2.html

Communication between Java programs with non-JDK objects

I'm looking for a communication channel between two java programs running on the same machine. I've found a few options (RMI and XML-RCP) but none of the examples that I found show exchange of objects wich class it's non-primitive and not know on JDK (our own objects).
So, what's the easy technology to use when I want to do this (note that Utils.jar it's on the classpath of Server.jar and Client.jar):
Utils.jar:
class MyClassRequestParams { ... }
class MyClassReturnParams { ... }
Client.jar:
// Server creation
...
// Send request
MyClassRequestParams params = new MyClass...
MyClassReturnParams response = server.send("serverMethodName", params);
Server.jar:
MyClassRequestParams serverMethodName(MyClassRequestParams params)
{
MyClassReturnParams response = new MyC...
// do processing
return response;
}
Just make your transport classes implement the Serializable interface, and everything will be fine with RMI. Note that every object referenced bt the transport object should also be Serializable.
The RMI tutorial uses an example with a custom Task interface implemented by a Pi custom class that is not a "standard" JDK class.
You may also consider Versile Java (I am one of its developers). Follow the link for an example of making remote calls and defining remote interfaces. It implements a platform-independent standard for remote ORB interaction, currently also available for python.

How do you tell the reference path when loading a class?

I'm trying to use JavaLoader to load a java (HttpAsyncClient) class into ColdFusion.
client = loader.create("org.apache.commons.HttpAsyncClient")
How do we know the reference that is org.apache.commons.HttpAsyncClient? I thought if you open the jar file and follow the directory structure, it will give you the reference path. But I don't think this is true.
I'm trying to use the HttpAsyncClient but I'm unable to load it:
client = loader.create("org.apache.commons.HttpAsyncClient") returns a class not found error.
Loader is a reference to JavaLoader, which loads Java classes into your CF server.
Rather than reinvent the wheel, why not try an existing tool like Mark Mandel's AsyncHTTP library?
Update: From the comments, that tool is ACF only. So you might try using the concrete class DefaultHttpAsyncClient as shown in the Asynchronous HTTP Exchange example.
I don't know ColdFusion. You probably have to specify the full path to the class, not just the package containing the class.
According to an example I found the full package and class name is this: org.apache.http.nio.client.HttpAsyncClient
You can also use the javadoc to find out the package and class names: http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/index.html
Getting something async going with an interface like this will probably be brutal. I would suggest trying the sync version first.
EDIT
I would try adapting this sync example to CF: http://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientWithResponseHandler.java
When you instantiate HttpGet you have to pass extra parameters to init() as they do in this example: http://www.coldfusionjedi.com/index.cfm/2009/5/29/Generating-Speech-with-ColdFusion-and-Java

Categories

Resources