exaclty... I looked on HttpServlet... request and response are passed as parameters... 
so I don't HAVE it. And since it's passed as a parameter I would have to change 150 
JSPs to pass this new parameter...
 
and I don't wanna change anything, only create a new class... if in the solution comes 
changing all the JSPs and classes I'm sure that's not the best one... I may have asked 
the wrong question... let's say:
 
public class TesteDispatcher extends HttpServlet {
    private static final String CONTENT_TYPE = "text/html";
 
 //Initialize global variables
    public void init() throws ServletException {
    }
 
 //Clean up resources
    public void destroy() {
    }
 
 public String doSomething() {
  // this is the method...
 }
}
 
Is there anyway doSomething() can know in which Context it was called? Remember that 
this class is in \common\classes.
 
thanks for ur patience
 
 
.:| Christian J. Dechery
.:| FINEP - Depto. de Sistemas
.:| [EMAIL PROTECTED]
.:| (21) 2555-0332

>>> [EMAIL PROTECTED] 10/07/02 14:23 >>> 

Hi, Christian. 

I would recommend now taking a good look at the Java Servlet 
Specification and letting all these suggestions digest while you go through 
that. Things should start to make more sense once you have a better handle on 
servlets. Maybe take a look at the Tomcat servlet examples too. 

Your servlet should definitely have access to the request object, since 
if you look at the specs on HttpServlet, you'll see that it is passed as a 
parameter to its various methods. 

HTH, 
-Jeff 




"Christian J. 
Dechery" To: < [EMAIL PROTECTED] > 
<christian@fin cc: 
ep.gov.br> Subject: Re: Need Ideas... big problem! (long) 

07/10/02 12:30 
PM 
Please respond 
to "Tomcat 
Users List" 






But I want the code I would write in the A class... cuz I will create a 
Servlet to provide a connection to the JSPs, but I don't wanna change the 
JSPs... inside my Servlet (A) I don't have access to the request object. 

Could u write some example code for the A class to figure in which context the 
method doSomething() was called? 

Thanks... 

.:| Christian J. Dechery 
.:| FINEP - Depto. de Sistemas 
.:| [EMAIL PROTECTED] 
.:| (21) 2555-0332 

>>> [EMAIL PROTECTED] 10/07/02 13:51 >>> 


On Wed, 10 Jul 2002, Christian J. Dechery wrote: 

> Date: Wed, 10 Jul 2002 13:27:26 -0300 
> From: Christian J. Dechery < [EMAIL PROTECTED] > 
> Reply-To: Tomcat Users List < [EMAIL PROTECTED] > 
> To: [EMAIL PROTECTED] 
> Subject: Re: Need Ideas... big problem! (long) 
> 
> I'm having some difficulty understanding the solution u guys provided me... 
maybe I explained my problem badly, so u aren't fully understanding it... 
> 
> but I have a question that is quite simple: Is it possible for a class 
> (or Servlet) located in $tomcat_home\common\classes - that will be 
> accessed from all webapps - to know from which context a JSP/Servlet 
> called it? 
> 
> for example... I have a class A in common\classes and it has a method 
doSomething()... say I have a JSP $tomcat_home\webapps\test\1.jsp that looks 
something like: 
> 
> <%@page import="A"%> 
> <% 
> String x = A.doSomething(); 
> %> 
> 
> so... would it be possible for A to know that when doSomething() was 
> called, the context was "test"? 
> 

Sure ... that's really easy. You've got at least the following options: 

* Call request.getContextPath() and you'll get the context path of the 
web application that is responding to this request. 

* The "application" object in a JSP page is in fact the ServletContext 
for the current webapp, so you can call things like 

<% 
Properties props = new Properties(); 
InputStream stream = 
application.getResourceAsStream("/WEB-INF/myprops.properties"); 
props.load(stream); 
stream.close(); 
%> 

to load a properties file from inside the WEB-INF subdirectory of your web 
application. 

As a general note, however, you should really be doing this sort of thing 
in startup code of a servlet, which stashes the results as servlet context 
parameters for everyone else to use. Using scriptlets to mix functional 
logic into your JSP pages is going to cause you maintenance nightmares 
over time. 

Craig 


-- 
To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED] > 
For additional commands, e-mail: < mailto:[EMAIL PROTECTED] 
> 








-- 
To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED] > 
For additional commands, e-mail: < mailto:[EMAIL PROTECTED] > 



Reply via email to