File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes Dynamically invoke servlets across contexts using reflection Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Dynamically invoke servlets across contexts using reflection" Watch "Dynamically invoke servlets across contexts using reflection" New topic
Author

Dynamically invoke servlets across contexts using reflection

Vijay Giri
Greenhorn

Joined: Apr 07, 2012
Posts: 2

I have two servlets hosted on different web applications. I'm trying to invoke the servlet in App(2) from App(1) through dynamic method call i.e. trigger the doPost() by passing the servlet request and response objects as arguments.

Now the reason for this ... its because I would like to reuse the original session object (created in App 1) and its attributes when I 'hand over' the request object from one servlet to another. The entire exchange gets broken if I were to invoke an explicit URL call to the second servlet using the java.net class , for example.

In simple terms, I'm trying to create a chain of servlet interaction across different web application contexts by dynamically invoking the doPost method and passing the request & response arguments for the "same" client request as a single operation. Is it possible using Java reflection ?

The Request Dispatcher didn't help since it works only within the current application context.

I've tried the following code to trigger the doPost method. So far , the list of methods pertaining to the servlet class prints correctly but I'm unable to obtain the specific doPost method object handle due to this error :: 'java.lang.NoSuchMethodException : No such method exists' - which I don't understand since I'm able to see the method listed in the debugging trace.


Constructor lvoConstructor = lvoClass.getConstructor();

// Trace debugging, see output
for(Method m : lvoClass.getDeclaredMethods())
{
cvoFileManager.writeFile("Method-->"+m.getName());
Class ptyp[] = m.getParameterTypes();
for (int j = 0; j < ptyp.length; j++)
cvoFileManager.writeFile("param #" + j + " " + ptyp[j]);
}
//prints all the declared methods (including doPost)

Class t1 = Class.forName("javax.servlet.http.HttpServletRequest");
Class t2 = Class.forName("javax.servlet.http.HttpServletResponse");
//create the class array
Class[] types = new Class[] {t1,t2};
//get the method object
Method lvoMethod = lvoClass.getDeclaredMethod("doPost",types); //[fails here]

<< Debug Trace >>

Method-->doGet
param #0 interface javax.servlet.http.HttpServletRequest
param #1 interface javax.servlet.http.HttpServletResponse
Method-->doPost
param #0 interface javax.servlet.http.HttpServletRequest
param #1 interface javax.servlet.http.HttpServletResponse


I'm able to instantiate the servlet class by using my own custom class loader so that takes care of locating the required .class file.

I noticed that the parameters printed for doPost say that the HttpServletRequest & Response are interfaces. Not sure if that is causing a problem in the argument definition. Maybe I'm overlooking something very fundamental.

Any suggestions/ideas ?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61596
    
  67

That approach is not going to work in any way shape or form.

If you want to re-use the servlet code, the best way to do it is to factor the common code out into a class that you can build into both applications.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Vijay Giri
Greenhorn

Joined: Apr 07, 2012
Posts: 2

Just thought I'll share my learning from this ... the classLoader I used to load the second servlet class was different from the classLoader used to instantiate the HttpServlet request and response objects in the first servlet - that's why the respective doPost method object could not be detected/created.

On the same note .. it means that servlets across contexts cannot be instantiated unless they all (class & method signature) share the same classLoader footprint - not sure if someone has tried this though.
Piyush Mangal
Ranch Hand

Joined: Jan 22, 2007
Posts: 196
Vijay Giri wrote:Just thought I'll share my learning from this ... the classLoader I used to load the second servlet class was different from the classLoader used to instantiate the HttpServlet request and response objects in the first servlet - that's why the respective doPost method object could not be detected/created.

On the same note .. it means that servlets across contexts cannot be instantiated unless they all (class & method signature) share the same classLoader footprint - not sure if someone has tried this though.


For you information, all web containers have custom class loader (they load classes from WEB-INF/classes and jars from WEB-INF/libs). Application server like JBoss by default uses different class loaders for different war as well.


 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Dynamically invoke servlets across contexts using reflection