I'm +0 on keeping the jars in the WAR. If a user is purposely adding a
listener, he can purposely copy a few jars to web-inf/lib. Its
documented as such. Following what most users on axis-users are doing
with spring anyways, most want to put spring in an aar . In that case,
they'd be just moving the jars from web-inf/lib into the aar.

We'd be asking most of our users - which will not be using spring - to
carry around 500K they don't use. And the majority of those that do,
they will probably want the full 2 meg spring jar for more features.
And most probably will just move the jars into the aar. Then there is
spring 2 that's getting close, as 1.2.8 has been out a year. I'm a big
advocate of spring and pushed getting the support in, but at the same
time, the benefits of keeping the spring jars in the war to me don't
match what most spring users will be doing as I see it.

I see your concern, but its currently documented that the jars need to
be copied over.

Robert

On 10/13/06, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote:
Hi Robert,

In the Spring WAR case, according to the xdoc one has to write the following
in the web.xml
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>
<context-param>
 <param-name>contextConfigLocation</param-name>
 <param-value>/WEB-INF/applicationContext.xml</param-value>
 </context-param>



If above is specified and .aar not available in services folder, we might
face a serious situation of ClassNotFound.

In order to get this work IMHO spring jars should be available in root lib/.
Besides, if the service specifies RPCMessageReceiver, deployment engines
asked for the service class from serviceObjectSupplier. At deployment time
we are not set and remove the TCCL as we need as in AbstractMessageReceive,
which is kind a ugly IMHO. If the spring-*.jars are not available in root
lib/ we will loose the nice features of having ?wsdl, ?xsd ect. Thus, for
WAR IMHO we need to include spring.jar. Std-dist, I agree we don't need to
supply spring.jars.

Beside, the needed jars spring-beans-1.2.8.jar, spring-context-1.2.8.jar,
spring-core-1.2.8.jar and spring-web-1.2.8.jar will sum up to 594 K. Thus,
if there are 20+ spring related services available in embedded system,
giving these jars with WAR is a good deal.

Thank you

Saminda





On 10/13/06, robert lazarski <[EMAIL PROTECTED]> wrote:
>
> IMHO:
>
> 1) None of the spring stuff should be included in the WAR. These jars
> might be placed inside the AAR if a user chooses to do so, so its
> really up to the user where to put these jars. This is the way it was
> and is documented as such.
>
> 2) The std-bin distro should not include the spring-* jars that come
> from the spring framework distro. These are compile deps and runtime
> deps for the unit tests. The std-bin should only contain
> axis2-spring-*.jar . This is the way it was and is documented as such.
>
> Thanks,
> Robert
>
> On 10/13/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote:
> > Hi Devs,
> > We found that we have shipped some unnecessary libraries with the
> > Axis2-RC1 distributions.. I created the following lists to capture
> > what to include, what not to include... Please do review them and add
> > your suggestions..
> >
> >
http://wiki.apache.org/ws/FrontPage/Axis2/axis2_war_build_list
> >
http://wiki.apache.org/ws/FrontPage/Axis2/axis2_min_build_list
> >
http://wiki.apache.org/ws/FrontPage/Axis2/axis2_std_build_list
> >
> > Thanks,
> > Thilina
> >
> > --
> > http://webservices.apache.org/~thilina/
> > http://thilinag.blogspot.com/
> >
> >
---------------------------------------------------------------------
> > 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]
>
>



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

Reply via email to