It seems that we should stick with the 2.5 version and use the jar from geronimo. Please note "provided" scope is used for compilation too.

Thanks,
Raymond

----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, November 13, 2007 9:21 AM
Subject: Re: servlet-api jar proposed change



Simon Laws wrote:

On Nov 13, 2007 4:22 PM, Simon Nash <[EMAIL PROTECTED]> wrote:


There is one place in binding-ws-axis2 where we use a 2.5-only
method.  It's in Axis2ServiceServlet.createDummyServletConfig() where
we use the getContextPath() method of the ServletContext class.

Is it OK to remove this method and go back to a 2.4 compile
dependency?  I tried doing this and the generated war ran OK in
Tomcat 6.0.14.  Why do we currently use this method and have the
2.5 dependency if everything is OK without it?

 Simon

ant elder wrote:


Do we want to support pre-2.5 level servlet containers? If so then maybe

we

should use the 2.4 version so things don't inadvertently use 2.5 only

APIs.

  ...ant

On Nov 13, 2007 1:59 PM, Ignacio Silva-Lepe <[EMAIL PROTECTED]>

wrote:


This sounds like a useful change to get all of our dependencies on
servlet-api in sync. And, as you say, it does not seem to have any
negative impact.
+1 from me.

Thanks

On Nov 13, 2007 8:43 AM, Simon Nash <[EMAIL PROTECTED]> wrote:


When the embedded Tomcat server starts, it produces a series of

warnings

as shown in the "->" markings below.

   [java] 13-Nov-2007 11:57:56

org.apache.catalina.core.StandardEnginestart

   [java] INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
   [java] 13-Nov-2007 11:57:56

org.apache.catalina.startup.ContextConfig defaultWebConfig


   [java] INFO: No default web.xml
->   [java] 13-Nov-2007 11:57:57

org.apache.catalina.startup.DigesterFactory register


->   [java] WARNING: Could not get url for

/javax/servlet/jsp/resources/jsp_2_0.xsd


->   [java] 13-Nov-2007 11:57:57

org.apache.catalina.startup.DigesterFactory register


->   [java] WARNING: Could not get url for

/javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd


->   [java] 13-Nov-2007 11:57:57

org.apache.catalina.startup.DigesterFactory register


->   [java] WARNING: Could not get url for

/javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd


->   [java] 13-Nov-2007 11:57:57

org.apache.catalina.startup.DigesterFactory register


->   [java] WARNING: Could not get url for

/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd


->   [java] 13-Nov-2007 11:57:57

org.apache.catalina.startup.DigesterFactory register


->   [java] WARNING: Could not get url for

/javax/servlet/resources/j2ee_web_services_1_1.xsd


   [java] 13-Nov-2007 11:57:57

org.apache.coyote.http11.Http11Protocolinit

   [java] INFO: Initializing Coyote HTTP/1.1 on http-8085
   [java] 13-Nov-2007 11:57:57

org.apache.coyote.http11.Http11Protocolstart

   [java] INFO: Starting Coyote HTTP/1.1 on http-8085
   [java] 13-Nov-2007 11:57:57

org.apache.tuscany.sca.http.tomcat.TomcatServer addServletMapping


   [java] INFO: Added Servlet mapping:

http://localhost:8085/HelloWorldService


I have tracked down the cause of these warnings.  The servlet-api jar

that we


are using is not the servlet-api jar that comes with Tomcat.  We are

using the


Sun reference implementation for this jar, and this does not contain

all

the


resources expected by Tomcat.  These missing resources cause the

warnings to


be produced.

To eliminate the warnings, the following changes are needed:
1) Use a different servlet-api jar that contains all the necessary

servlet


 resources.
2) For the embedded Tomcat environment, also include a jsp-api jar so

that


 the jsp-related resources can be picked up from this jar.

For 1), there are many possible jars we could use.  After some

investigation,


it seems that the servlet-api jar that ships with Geronimo is the best

choice,


as it contains all the necessary resources and has an Apache license

with no


dependency on Sun code.  For 2), the jsp-api jar from Geronimo also

seems to


be a good choice for similar reasons.

At the moment, many SCA poms contain a mixture of "provided" and "test"
references to the 2.4 and 2.5 levels of servlet-api.  I don't see any
reason for this mixture (a "compile" dependency would be a different

matter).


The only modules with "compile" dependencies are host-tomcat and

host-jetty,


and these are already using 2.5 (the Sun version).  I went through the

poms


changing all of the servlet-api dependencies to use the Geronimo

2.5version,

and I also added a Geronimo jsp-api 2.1 dependency to host-tomcat.

With

these changes, everything builds OK and runs in both the embedded and
webapp environments, including both Tomcat 5.5.x and 6.0.x, with no

warning


messages.

Does anyone have any concerns about my putting these changes into

trunk?

Simon



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





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

I think in that case it's just there in case 2.5 is used.


Simon


I tried removing this method and compiling against 2.4, and it seemed
to work ok with both Tomcat 6 and Jetty 6 (embedded) and with Tomcat 6
(webapp).  Maybe my simple test wasn't exercising the path that would
have called this method.  Any ideas for a use case that could result
in this method being called?

If there is such a use case, then I think it may still be OK to compile
against 2.4 as long as we include the extra method.  If the 2.5 interface
is loaded at runtime and the getContextPath() method is called through
that interface, then I think Java will find the method even though the
2.5 interface wasn't present at compile time.  It would be good to test
this out, though.

  Simon



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



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

Reply via email to