You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gd...@macromedia.com> on 2001/10/04 21:28:10 UTC
RE: AW: Patch for Context Class Loader problems (was Re: Fresh CV
S ch eckout - AdminClient list fails)
OK, got a problem for you. :)
JRun is integrating Web Services into our next version of the app server,
and we have a tech preview going out on our current version demonstrating
this stuff. It uses Axis, and puts the axis.jar into a system-level lib/
directory so it's automatically accessible via all webapps. (do you see
where I'm going yet?) Thus the AxisServlet class is actually loaded by a
JRun-wide class loader, *not* the webapp-specific classloader which has
access to the WEB-INF/classes directories, etc.
So this patch don't work for us. We do however set the context classloader
correctly - so I think we're gonna have to change the patch to only set it
if it's not set. Now if there is a performance hit associated with the
check, I'd suggest we check it once and store the result in a flag that
indicates we don't need to check it again.
--Glen
> -----Original Message-----
> From: Davanum Srinivas [mailto:dims@yahoo.com]
> Sent: Thursday, October 04, 2001 12:23 PM
> To: axis-dev@xml.apache.org
> Subject: Re: AW: Patch for Context Class Loader problems (was
> Re: Fresh
> CVS ch eckout - AdminClient list fails)
>
>
> Glen, Dr. Jung,
>
> I looked into the patches. I don't think my patch will
> interfere with Dr Jung's code at all. I
> again re-state the problem. Under some of the old Servlet
> Engines like Tomcat 3.2.3 if you print
> the Thread.currentThread().getContextClassLoader() in
> AxisServlet's init function. It will print
> "sun.misc.Launcher$AppClassLoader@71732b" which is the system
> default class (see
> http://www.jguru.com/faq/view.jsp?EID=4318). This is because
> the Servlet Engine does not set the
> Context Class Loader at all. This is exactly what my patch does.
>
> Now if the patch that i sent leads to problems, i promise to
> send in patches to fix them or will
> ask you guys to comment the line out........This should not
> be that difficult.
>
> Thanks,
> dims
>
> --- "Jung , Dr. Christoph" <ch...@infor.de> wrote:
> > -----Ursprüngliche Nachricht-----
> > >Von: Davanum Srinivas [mailto:dims@yahoo.com]
> > >Gesendet: Donnerstag, 4. Oktober 2001 17:25
> > >An: Tom Jordahl
> > >Cc: axis-dev@xml.apache.org
> > >Betreff: RE: Patch for Context Class Loader problems (was
> Re: Fresh CVS
> > >ch eckout - AdminClient list fails)
> >
> > >No Tom. Dr. J's comment was that there should be a better
> class-loading
> > mechanism for all the
> > >things that need to be picked up at runtime that are not
> available to the
> > class loader that loaded
> > >the Axis Servlet. I absolutely agree with this. But that
> does not mean that
> > my fix will stop us
> > >from implenting such a mechanism.
> >
> > I absolutely agree, my comment was just to extend a bit on
> the important
> > classloader issue. I
> > didn´t want to confuse, sorry.
> >
> > >Talking theoretical is great!!! We have a real-world
> project that has to be
> > implemented on some
> > >Servlet Engines in a production environment for which we need a FIX
> > NOW!!!!. After all you can
> > >comment out the single line of code ANYTIME!!!!
> >
> > Attached is my work-around to that problem. The diff refactors
> > org.apache.axis.transports.http.AxisServlet
> > such that subclasses
> (org.jboss.net.axis.AxisServiceServlet) can produce
> > different MessageContexts (here
> > org.jboss.net.axis.ClassLoaderAwareMessageContext).
> >
> > The org.jboss.net.axis.ClassLoaderAwareMessageContext in
> conjunction with
> > the org.jboss.net.axis.ClassLoaderAwareAxisServer is able
> to reestablish the
> > right
> > service classloader while doing a setTargetService(String
> serviceName).
> >
> > Maybe that also solves the problem of Mr. Srinivas? As said
> before, having
> > the deployment classloader being associated with every
> deployable item for
> > further resolution would IMHO be a better design.
> >
> > Best,
> > CGJ
> >
> >
> >
> >
> >
>
> > ATTACHMENT part 2 application/octet-stream name=AxisServlet.diff
>
>
> > ATTACHMENT part 3 application/octet-stream
> name=ClassLoaderAwareMessageContext.java
>
>
> > ATTACHMENT part 4 application/octet-stream
> name=ClassLoaderAwareAxisServer.java
>
>
> > ATTACHMENT part 5 application/octet-stream
> name=AxisServiceServlet.java
>
>
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting,
> just $8.95/month.
> http://geocities.yahoo.com/ps/info1
>
Re: AW: Patch for Context Class Loader problems (was Re: Fresh CV S
checkout - AdminClient list fails)
Posted by Ravi Kumar <rk...@borland.com>.
Glen,
I think I had brought this up earlier ...
Isn't what you are proposing (for JRun) incorrect behaviour as per the Servlet
spec?
Isn't a context expected to be self contained and isolated from whatever is in
the container's classpath?
Rgds
Ravi
Glen Daniels wrote:
> OK, got a problem for you. :)
>
> JRun is integrating Web Services into our next version of the app server,
> and we have a tech preview going out on our current version demonstrating
> this stuff. It uses Axis, and puts the axis.jar into a system-level lib/
> directory so it's automatically accessible via all webapps. (do you see
> where I'm going yet?) Thus the AxisServlet class is actually loaded by a
> JRun-wide class loader, *not* the webapp-specific classloader which has
> access to the WEB-INF/classes directories, etc.
>
> So this patch don't work for us. We do however set the context classloader
> correctly - so I think we're gonna have to change the patch to only set it
> if it's not set. Now if there is a performance hit associated with the
> check, I'd suggest we check it once and store the result in a flag that
> indicates we don't need to check it again.
>
> --Glen
>
> > -----Original Message-----
> > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > Sent: Thursday, October 04, 2001 12:23 PM
> > To: axis-dev@xml.apache.org
> > Subject: Re: AW: Patch for Context Class Loader problems (was
> > Re: Fresh
> > CVS ch eckout - AdminClient list fails)
> >
> >
> > Glen, Dr. Jung,
> >
> > I looked into the patches. I don't think my patch will
> > interfere with Dr Jung's code at all. I
> > again re-state the problem. Under some of the old Servlet
> > Engines like Tomcat 3.2.3 if you print
> > the Thread.currentThread().getContextClassLoader() in
> > AxisServlet's init function. It will print
> > "sun.misc.Launcher$AppClassLoader@71732b" which is the system
> > default class (see
> > http://www.jguru.com/faq/view.jsp?EID=4318). This is because
> > the Servlet Engine does not set the
> > Context Class Loader at all. This is exactly what my patch does.
> >
> > Now if the patch that i sent leads to problems, i promise to
> > send in patches to fix them or will
> > ask you guys to comment the line out........This should not
> > be that difficult.
> >
> > Thanks,
> > dims
> >
> > --- "Jung , Dr. Christoph" <ch...@infor.de> wrote:
> > > -----Ursprüngliche Nachricht-----
> > > >Von: Davanum Srinivas [mailto:dims@yahoo.com]
> > > >Gesendet: Donnerstag, 4. Oktober 2001 17:25
> > > >An: Tom Jordahl
> > > >Cc: axis-dev@xml.apache.org
> > > >Betreff: RE: Patch for Context Class Loader problems (was
> > Re: Fresh CVS
> > > >ch eckout - AdminClient list fails)
> > >
> > > >No Tom. Dr. J's comment was that there should be a better
> > class-loading
> > > mechanism for all the
> > > >things that need to be picked up at runtime that are not
> > available to the
> > > class loader that loaded
> > > >the Axis Servlet. I absolutely agree with this. But that
> > does not mean that
> > > my fix will stop us
> > > >from implenting such a mechanism.
> > >
> > > I absolutely agree, my comment was just to extend a bit on
> > the important
> > > classloader issue. I
> > > didn´t want to confuse, sorry.
> > >
> > > >Talking theoretical is great!!! We have a real-world
> > project that has to be
> > > implemented on some
> > > >Servlet Engines in a production environment for which we need a FIX
> > > NOW!!!!. After all you can
> > > >comment out the single line of code ANYTIME!!!!
> > >
> > > Attached is my work-around to that problem. The diff refactors
> > > org.apache.axis.transports.http.AxisServlet
> > > such that subclasses
> > (org.jboss.net.axis.AxisServiceServlet) can produce
> > > different MessageContexts (here
> > > org.jboss.net.axis.ClassLoaderAwareMessageContext).
> > >
> > > The org.jboss.net.axis.ClassLoaderAwareMessageContext in
> > conjunction with
> > > the org.jboss.net.axis.ClassLoaderAwareAxisServer is able
> > to reestablish the
> > > right
> > > service classloader while doing a setTargetService(String
> > serviceName).
> > >
> > > Maybe that also solves the problem of Mr. Srinivas? As said
> > before, having
> > > the deployment classloader being associated with every
> > deployable item for
> > > further resolution would IMHO be a better design.
> > >
> > > Best,
> > > CGJ
> > >
> > >
> > >
> > >
> > >
> >
> > > ATTACHMENT part 2 application/octet-stream name=AxisServlet.diff
> >
> >
> > > ATTACHMENT part 3 application/octet-stream
> > name=ClassLoaderAwareMessageContext.java
> >
> >
> > > ATTACHMENT part 4 application/octet-stream
> > name=ClassLoaderAwareAxisServer.java
> >
> >
> > > ATTACHMENT part 5 application/octet-stream
> > name=AxisServiceServlet.java
> >
> >
> >
> > =====
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting,
> > just $8.95/month.
> > http://geocities.yahoo.com/ps/info1
> >
Re: AW: Patch for Context Class Loader problems (was Re: Fresh CVS ch
eckout - AdminClient list fails)
Posted by Berin Loritsch <bl...@apache.org>.
Glen Daniels wrote:
>
> OK, got a problem for you. :)
>
> JRun is integrating Web Services into our next version of the app server,
> and we have a tech preview going out on our current version demonstrating
> this stuff. It uses Axis, and puts the axis.jar into a system-level lib/
> directory so it's automatically accessible via all webapps. (do you see
> where I'm going yet?) Thus the AxisServlet class is actually loaded by a
> JRun-wide class loader, *not* the webapp-specific classloader which has
> access to the WEB-INF/classes directories, etc.
Hmmm. You might have the parent classloader be the one from
HttpServlet.class.getClassLoader(). This ensures the environment you are
looking for--no matter where Axis is in the ClassLoader hierarchy.
> So this patch don't work for us. We do however set the context classloader
> correctly - so I think we're gonna have to change the patch to only set it
> if it's not set. Now if there is a performance hit associated with the
> check, I'd suggest we check it once and store the result in a flag that
> indicates we don't need to check it again.
Make sure that flag(s) takes into account that threads that access the
AxisServlet are likely to be pooled (i.e. more than one thread). The next
issue comes with Servlet 2.3 Filters that can also affect the contextClassLoader.
As I don't know whether the new version of JRun is Servlet 2.3 compliant,
I am not sure that this affects that environment.
>
> --Glen
Re: AW: Patch for Context Class Loader problems (was Re: Fresh CVS
checkout - AdminClient list fails)
Posted by Ravi Kumar <rk...@borland.com>.
Glen,
Does this patch address your concerns? If so, could we please get this in?
Rgds
Ravi
JBuilder R&D
Davanum Srinivas wrote:
> Glen,
>
> Please see enclosed patch. In init, it will check if it can find
> "org.apache.axis.transport.http.AxisServlet". If this cannot be found then we got a bad context
> class loader from the ServletEngine so we set a flag for it and also set the context class loader
> to AxisServlet's class loader. Then in service we check the flag and set the context class loader
> if necessary.
>
> Thanks,
> dims
>
> --- Glen Daniels <gd...@macromedia.com> wrote:
> >
> > OK, got a problem for you. :)
> >
> > JRun is integrating Web Services into our next version of the app server,
> > and we have a tech preview going out on our current version demonstrating
> > this stuff. It uses Axis, and puts the axis.jar into a system-level lib/
> > directory so it's automatically accessible via all webapps. (do you see
> > where I'm going yet?) Thus the AxisServlet class is actually loaded by a
> > JRun-wide class loader, *not* the webapp-specific classloader which has
> > access to the WEB-INF/classes directories, etc.
> >
> > So this patch don't work for us. We do however set the context classloader
> > correctly - so I think we're gonna have to change the patch to only set it
> > if it's not set. Now if there is a performance hit associated with the
> > check, I'd suggest we check it once and store the result in a flag that
> > indicates we don't need to check it again.
> >
> > --Glen
> >
> > > -----Original Message-----
> > > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > > Sent: Thursday, October 04, 2001 12:23 PM
> > > To: axis-dev@xml.apache.org
> > > Subject: Re: AW: Patch for Context Class Loader problems (was
> > > Re: Fresh
> > > CVS ch eckout - AdminClient list fails)
> > >
> > >
> > > Glen, Dr. Jung,
> > >
> > > I looked into the patches. I don't think my patch will
> > > interfere with Dr Jung's code at all. I
> > > again re-state the problem. Under some of the old Servlet
> > > Engines like Tomcat 3.2.3 if you print
> > > the Thread.currentThread().getContextClassLoader() in
> > > AxisServlet's init function. It will print
> > > "sun.misc.Launcher$AppClassLoader@71732b" which is the system
> > > default class (see
> > > http://www.jguru.com/faq/view.jsp?EID=4318). This is because
> > > the Servlet Engine does not set the
> > > Context Class Loader at all. This is exactly what my patch does.
> > >
> > > Now if the patch that i sent leads to problems, i promise to
> > > send in patches to fix them or will
> > > ask you guys to comment the line out........This should not
> > > be that difficult.
> > >
> > > Thanks,
> > > dims
> > >
> > > --- "Jung , Dr. Christoph" <ch...@infor.de> wrote:
> > > > -----Ursprüngliche Nachricht-----
> > > > >Von: Davanum Srinivas [mailto:dims@yahoo.com]
> > > > >Gesendet: Donnerstag, 4. Oktober 2001 17:25
> > > > >An: Tom Jordahl
> > > > >Cc: axis-dev@xml.apache.org
> > > > >Betreff: RE: Patch for Context Class Loader problems (was
> > > Re: Fresh CVS
> > > > >ch eckout - AdminClient list fails)
> > > >
> > > > >No Tom. Dr. J's comment was that there should be a better
> > > class-loading
> > > > mechanism for all the
> > > > >things that need to be picked up at runtime that are not
> > > available to the
> > > > class loader that loaded
> > > > >the Axis Servlet. I absolutely agree with this. But that
> > > does not mean that
> > > > my fix will stop us
> > > > >from implenting such a mechanism.
> > > >
> > > > I absolutely agree, my comment was just to extend a bit on
> > > the important
> > > > classloader issue. I
> > > > didn´t want to confuse, sorry.
> > > >
> > > > >Talking theoretical is great!!! We have a real-world
> > > project that has to be
> > > > implemented on some
> > > > >Servlet Engines in a production environment for which we need a FIX
> > > > NOW!!!!. After all you can
> > > > >comment out the single line of code ANYTIME!!!!
> > > >
> > > > Attached is my work-around to that problem. The diff refactors
> > > > org.apache.axis.transports.http.AxisServlet
> > > > such that subclasses
> > > (org.jboss.net.axis.AxisServiceServlet) can produce
> > > > different MessageContexts (here
> > > > org.jboss.net.axis.ClassLoaderAwareMessageContext).
> > > >
> > > > The org.jboss.net.axis.ClassLoaderAwareMessageContext in
> > > conjunction with
> > > > the org.jboss.net.axis.ClassLoaderAwareAxisServer is able
> > > to reestablish the
> > > > right
> > > > service classloader while doing a setTargetService(String
> > > serviceName).
> > > >
> > > > Maybe that also solves the problem of Mr. Srinivas? As said
> > > before, having
> > > > the deployment classloader being associated with every
> > > deployable item for
> > > > further resolution would IMHO be a better design.
> > > >
> > > > Best,
> > > > CGJ
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > > ATTACHMENT part 2 application/octet-stream name=AxisServlet.diff
> > >
> > >
> > > > ATTACHMENT part 3 application/octet-stream
> > > name=ClassLoaderAwareMessageContext.java
> > >
> > >
> > > > ATTACHMENT part 4 application/octet-stream
> > > name=ClassLoaderAwareAxisServer.java
> > >
> > >
> > > > ATTACHMENT part 5 application/octet-stream
> > > name=AxisServiceServlet.java
> > >
> > >
> > >
> > > =====
> > > Davanum Srinivas, JNI-FAQ Manager
> > > http://www.jGuru.com/faq/JNI
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > NEW from Yahoo! GeoCities - quick and easy web site hosting,
> > > just $8.95/month.
> > > http://geocities.yahoo.com/ps/info1
> > >
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
> http://geocities.yahoo.com/ps/info1
>
> ------------------------------------------------------------------------
> Index: java/src/org/apache/axis/transport/http/AxisServlet.java
> ===================================================================
> RCS file: /home/cvs/xml-axis/java/src/org/apache/axis/transport/http/AxisServlet.java,v
> retrieving revision 1.50
> diff -u -r1.50 AxisServlet.java
> --- java/src/org/apache/axis/transport/http/AxisServlet.java 2001/10/04 14:36:50 1.50
> +++ java/src/org/apache/axis/transport/http/AxisServlet.java 2001/10/05 11:53:08
> @@ -95,7 +95,20 @@
>
> private static final String AXIS_ENGINE = "AxisEngine" ;
>
> + private static boolean setContextClassLoader = false;
> +
> public void init() {
> +
> + // HACK: Check if the Servlet Engine is setting the context class loader properly.
> + // If not we need to set it ourselves.
> + ClassLoader cl = Thread.currentThread().getContextClassLoader();
> + try {
> + Class clazz = cl.loadClass("org.apache.axis.transport.http.AxisServlet");
> + } catch (Exception e){
> + setContextClassLoader = true;
> + Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
> + }
> +
> String param = getInitParameter("transport.name");
> ServletContext context = getServletConfig().getServletContext();
>
> @@ -108,6 +121,14 @@
> if ((param != null) && (param.equalsIgnoreCase("true"))) {
> securityProvider = new ServletSecurityProvider();
> }
> + }
> +
> +
> + protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
> + if(setContextClassLoader) {
> + Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
> + }
> + super.service(req,res);
> }
>
> public AxisServer getEngine() {
RE: AW: Patch for Context Class Loader problems (was Re: Fresh CVS ch eckout - AdminClient list fails)
Posted by Davanum Srinivas <di...@yahoo.com>.
Glen,
Please see enclosed patch. In init, it will check if it can find
"org.apache.axis.transport.http.AxisServlet". If this cannot be found then we got a bad context
class loader from the ServletEngine so we set a flag for it and also set the context class loader
to AxisServlet's class loader. Then in service we check the flag and set the context class loader
if necessary.
Thanks,
dims
--- Glen Daniels <gd...@macromedia.com> wrote:
>
> OK, got a problem for you. :)
>
> JRun is integrating Web Services into our next version of the app server,
> and we have a tech preview going out on our current version demonstrating
> this stuff. It uses Axis, and puts the axis.jar into a system-level lib/
> directory so it's automatically accessible via all webapps. (do you see
> where I'm going yet?) Thus the AxisServlet class is actually loaded by a
> JRun-wide class loader, *not* the webapp-specific classloader which has
> access to the WEB-INF/classes directories, etc.
>
> So this patch don't work for us. We do however set the context classloader
> correctly - so I think we're gonna have to change the patch to only set it
> if it's not set. Now if there is a performance hit associated with the
> check, I'd suggest we check it once and store the result in a flag that
> indicates we don't need to check it again.
>
> --Glen
>
> > -----Original Message-----
> > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > Sent: Thursday, October 04, 2001 12:23 PM
> > To: axis-dev@xml.apache.org
> > Subject: Re: AW: Patch for Context Class Loader problems (was
> > Re: Fresh
> > CVS ch eckout - AdminClient list fails)
> >
> >
> > Glen, Dr. Jung,
> >
> > I looked into the patches. I don't think my patch will
> > interfere with Dr Jung's code at all. I
> > again re-state the problem. Under some of the old Servlet
> > Engines like Tomcat 3.2.3 if you print
> > the Thread.currentThread().getContextClassLoader() in
> > AxisServlet's init function. It will print
> > "sun.misc.Launcher$AppClassLoader@71732b" which is the system
> > default class (see
> > http://www.jguru.com/faq/view.jsp?EID=4318). This is because
> > the Servlet Engine does not set the
> > Context Class Loader at all. This is exactly what my patch does.
> >
> > Now if the patch that i sent leads to problems, i promise to
> > send in patches to fix them or will
> > ask you guys to comment the line out........This should not
> > be that difficult.
> >
> > Thanks,
> > dims
> >
> > --- "Jung , Dr. Christoph" <ch...@infor.de> wrote:
> > > -----Urspr�ngliche Nachricht-----
> > > >Von: Davanum Srinivas [mailto:dims@yahoo.com]
> > > >Gesendet: Donnerstag, 4. Oktober 2001 17:25
> > > >An: Tom Jordahl
> > > >Cc: axis-dev@xml.apache.org
> > > >Betreff: RE: Patch for Context Class Loader problems (was
> > Re: Fresh CVS
> > > >ch eckout - AdminClient list fails)
> > >
> > > >No Tom. Dr. J's comment was that there should be a better
> > class-loading
> > > mechanism for all the
> > > >things that need to be picked up at runtime that are not
> > available to the
> > > class loader that loaded
> > > >the Axis Servlet. I absolutely agree with this. But that
> > does not mean that
> > > my fix will stop us
> > > >from implenting such a mechanism.
> > >
> > > I absolutely agree, my comment was just to extend a bit on
> > the important
> > > classloader issue. I
> > > didn�t want to confuse, sorry.
> > >
> > > >Talking theoretical is great!!! We have a real-world
> > project that has to be
> > > implemented on some
> > > >Servlet Engines in a production environment for which we need a FIX
> > > NOW!!!!. After all you can
> > > >comment out the single line of code ANYTIME!!!!
> > >
> > > Attached is my work-around to that problem. The diff refactors
> > > org.apache.axis.transports.http.AxisServlet
> > > such that subclasses
> > (org.jboss.net.axis.AxisServiceServlet) can produce
> > > different MessageContexts (here
> > > org.jboss.net.axis.ClassLoaderAwareMessageContext).
> > >
> > > The org.jboss.net.axis.ClassLoaderAwareMessageContext in
> > conjunction with
> > > the org.jboss.net.axis.ClassLoaderAwareAxisServer is able
> > to reestablish the
> > > right
> > > service classloader while doing a setTargetService(String
> > serviceName).
> > >
> > > Maybe that also solves the problem of Mr. Srinivas? As said
> > before, having
> > > the deployment classloader being associated with every
> > deployable item for
> > > further resolution would IMHO be a better design.
> > >
> > > Best,
> > > CGJ
> > >
> > >
> > >
> > >
> > >
> >
> > > ATTACHMENT part 2 application/octet-stream name=AxisServlet.diff
> >
> >
> > > ATTACHMENT part 3 application/octet-stream
> > name=ClassLoaderAwareMessageContext.java
> >
> >
> > > ATTACHMENT part 4 application/octet-stream
> > name=ClassLoaderAwareAxisServer.java
> >
> >
> > > ATTACHMENT part 5 application/octet-stream
> > name=AxisServiceServlet.java
> >
> >
> >
> > =====
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting,
> > just $8.95/month.
> > http://geocities.yahoo.com/ps/info1
> >
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1