Provider Classes

[Charles Rector <cr...@iexposure.com>]

Is it possible to explicitly reference a provider class with an absolute
path? I am having classpath woes.

A website I am developing with Enhydra 5.0 is dying when I include my site's
jar in multiserver's classpath (so SOAP will be able to find my services,
which exist as part of my site's code). Apparently this conflicts with the
jar which is specified in the classpath information for the site (Enhydra
5.0 application) from within multiserver's admin (the same jar). Although I
have tried specifying the jar on the multiserver classpath only, and
removing the reference to it from the site's specialized classpath in the
multiserver admin -- I still encountered the same problem.

The site works in concert with a standalone Java application, which has my
SOAP clients. When my site is dying, the standalone will run fine. But of
course, removing my site's jar from the multiserver classpath causes the
standalone to longer work, since it cannot find my SOAP services. So I can
get either my site or the standalone running, but not both at the same time.

It looks like I basically just need some way to tell SOAP where my provider
classes are without having to tweak the classpath for multiserver. Has
anybody experienced a similar dilemma before? I've been stumped on this for
over 2 weeks now, and I'm starting to feel a bit discouraged. :-(

--
Chuck Rector
Internet Exposure, Inc.
http://www.iexposure.com
crector@iexposure.com

Web Development - Web Marketing - ISP Services
(612) 676-1946

RE: Provider Classes

[Charles Rector <cr...@iexposure.com>]

Scott,

I apologize if I'm not completely clear on all that's involved -- I'm rather
new to all this. I've been developing websites in Enhydra for a year or so
now, but learning has generally been rushed and taken place mostly on a
need-to-know basis as I encounter stuff I haven't done before. A somewhat
uncomfortable and often frustrating spot to be in, but I need the money for
the time being. I always figure things out eventually -- this particular
problem is turning out to be one of the more time-consuming ones I've faced.

My site is not deployed as a Web application. Enhydra has the choices:
Application, Servlet, War. Most of our sites are Applications. I have Apache
SOAP deployed as a War on the same server as my site, thrown in there
alongside all of our other sites. My SOAP services are part of my
Application; I also use another Enhydra-related technology called DODS for
my data layer, and it's convenient to define my services directly in the
Application.

As far as the standalone app breaking when my jar is not in the multiserver
classpath; since I have SOAP deployed as a War within Enhydra's multiserver,
and my site's services deployed from the SOAP admin (which reference my
site's classes; for example, one provider class is pcp.SOAPService.PCPUser,
where pcp is my site's primary package), I include my site's jar in
multiserver's classpath so that the deployed SOAP War will be able to find
pcp.SOAPService.PCPUser. However, I only did that because that's all I could
think of to get my site's services found by the SOAP War.

I've noticed in Enhydra multiserver when viewing the info for the deployed
SOAP War that there is an Additional Classpaths item, which says None...
although when I modify the properties I don't see anywhere to add additional
classpaths like I can with Applications. I also read that the
WEB-INF/classes folder is automatically added to the classpath for wars, so
I tried decompressing my site jar into there and restarting the SOAP
service, but no luck.

As far as multiserver's classpath having anything to do with the standalone
app; it doesn't, directly. But the standalone app "connects" to the SOAP War
I deployed on multiserver in order to make use of my site's SOAP services,
which of course I have deployed from the SOAP admin. Hopefully that makes
some kind of sense.

I'm sure I've got something backwards, or have been looking in all the wrong
places for an answer. At any rate, I appreciate the comments. They've given
me a few things to think about so far. Still trying to wrap my thick head
around the problem...

--
Chuck Rector
Internet Exposure, Inc.
http://www.iexposure.com
crector@iexposure.com

Web Development - Web Marketing - ISP Services
(612) 676-1946

> -----Original Message-----
> From: Scott Nichol [mailto:snicholnews@scottnichol.com]
> Sent: Tuesday, November 26, 2002 8:38 AM
> To: soap-user@xml.apache.org
> Subject: Re: Provider Classes
>
>
> Charles,
>
> I am not sure how much help I will be, since I have not used Enhydra.  I
> can only speak from the perspective of the J2EE specification.
>
> Is your site deployed as a Web application, e.g. is it packaged as a war
> file?  Apache SOAP, and the services deployed on it, are usually part of
> a Web application or a separate Web application themselves.  In your
> case, it seems you could either deploy Apache SOAP and your services as
> part of the Web application for your site, or as a separate Web
> application.  Your jar can (should?) be deployed within each Web
> application, or once "globally".  I don't know how to translate this to
> Enhydra terminology, nor do I know if there are bugs related to this
> (Tomcat, for example, has had bugs with imperfect isolation of
> webapp-specific classes).
>
> Personally, I think it is better practice to put application code at the
> webapp level, even if this means you load multiple copies for multiple
> webapps.
>
> I do not understand why your standalone apps break if your jar is not in
> the multiserver classpath.  What should Enhydra's classpath have to do
> with a standalone app running in a separate VM?  You can always specify
> the standalone app's classpath with -classpath on the java command line,
> anyway.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Charles Rector" <cr...@iexposure.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, November 26, 2002 8:10 AM
> Subject: Provider Classes
>
>
> > Is it possible to explicitly reference a provider class with an
> absolute
> > path? I am having classpath woes.
> >
> > A website I am developing with Enhydra 5.0 is dying when I include my
> site's
> > jar in multiserver's classpath (so SOAP will be able to find my
> services,
> > which exist as part of my site's code). Apparently this conflicts with
> the
> > jar which is specified in the classpath information for the site
> (Enhydra
> > 5.0 application) from within multiserver's admin (the same jar).
> Although I
> > have tried specifying the jar on the multiserver classpath only, and
> > removing the reference to it from the site's specialized classpath in
> the
> > multiserver admin -- I still encountered the same problem.
> >
> > The site works in concert with a standalone Java application, which
> has my
> > SOAP clients. When my site is dying, the standalone will run fine. But
> of
> > course, removing my site's jar from the multiserver classpath causes
> the
> > standalone to longer work, since it cannot find my SOAP services. So I
> can
> > get either my site or the standalone running, but not both at the same
> time.
> >
> > It looks like I basically just need some way to tell SOAP where my
> provider
> > classes are without having to tweak the classpath for multiserver. Has
> > anybody experienced a similar dilemma before? I've been stumped on
> this for
> > over 2 weeks now, and I'm starting to feel a bit discouraged. :-(
> >
> > --
> > Chuck Rector
> > Internet Exposure, Inc.
> > http://www.iexposure.com
> > crector@iexposure.com
> >
> > Web Development - Web Marketing - ISP Services
> > (612) 676-1946
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>

RE: Provider Classes

[Charles Rector <cr...@iexposure.com>]

Scott,

I apologize if I'm not completely clear on all that's involved -- I'm rather
new to all this. I've been developing websites in Enhydra for a year or so
now, but learning has generally been rushed and taken place mostly on a
need-to-know basis as I encounter stuff I haven't done before. A somewhat
uncomfortable and often frustrating spot to be in, but I need the money for
the time being. I always figure things out eventually -- this particular
problem is turning out to be one of the more time-consuming ones I've faced.

My site is not deployed as a Web application. Enhydra has the choices:
Application, Servlet, War. Most of our sites are Applications. I have Apache
SOAP deployed as a War on the same server as my site, thrown in there
alongside all of our other sites. My SOAP services are part of my
Application; I also use another Enhydra-related technology called DODS for
my data layer, and it's convenient to define my services directly in the
Application.

As far as the standalone app breaking when my jar is not in the multiserver
classpath; since I have SOAP deployed as a War within Enhydra's multiserver,
and my site's services deployed from the SOAP admin (which reference my
site's classes; for example, one provider class is pcp.SOAPService.PCPUser,
where pcp is my site's primary package), I include my site's jar in
multiserver's classpath so that the deployed SOAP War will be able to find
pcp.SOAPService.PCPUser. However, I only did that because that's all I could
think of to get my site's services found by the SOAP War.

I've noticed in Enhydra multiserver when viewing the info for the deployed
SOAP War that there is an Additional Classpaths item, which says None...
although when I modify the properties I don't see anywhere to add additional
classpaths like I can with Applications. I also read that the
WEB-INF/classes folder is automatically added to the classpath for wars, so
I tried decompressing my site jar into there and restarting the SOAP
service, but no luck.

As far as multiserver's classpath having anything to do with the standalone
app; it doesn't, directly. But the standalone app "connects" to the SOAP War
I deployed on multiserver in order to make use of my site's SOAP services,
which of course I have deployed from the SOAP admin. Hopefully that makes
some kind of sense.

I'm sure I've got something backwards, or have been looking in all the wrong
places for an answer. At any rate, I appreciate the comments. They've given
me a few things to think about so far. Still trying to wrap my thick head
around the problem...

--
Chuck Rector
Internet Exposure, Inc.
http://www.iexposure.com
crector@iexposure.com

Web Development - Web Marketing - ISP Services
(612) 676-1946

> -----Original Message-----
> From: Scott Nichol [mailto:snicholnews@scottnichol.com]
> Sent: Tuesday, November 26, 2002 8:38 AM
> To: soap-user@xml.apache.org
> Subject: Re: Provider Classes
>
>
> Charles,
>
> I am not sure how much help I will be, since I have not used Enhydra.  I
> can only speak from the perspective of the J2EE specification.
>
> Is your site deployed as a Web application, e.g. is it packaged as a war
> file?  Apache SOAP, and the services deployed on it, are usually part of
> a Web application or a separate Web application themselves.  In your
> case, it seems you could either deploy Apache SOAP and your services as
> part of the Web application for your site, or as a separate Web
> application.  Your jar can (should?) be deployed within each Web
> application, or once "globally".  I don't know how to translate this to
> Enhydra terminology, nor do I know if there are bugs related to this
> (Tomcat, for example, has had bugs with imperfect isolation of
> webapp-specific classes).
>
> Personally, I think it is better practice to put application code at the
> webapp level, even if this means you load multiple copies for multiple
> webapps.
>
> I do not understand why your standalone apps break if your jar is not in
> the multiserver classpath.  What should Enhydra's classpath have to do
> with a standalone app running in a separate VM?  You can always specify
> the standalone app's classpath with -classpath on the java command line,
> anyway.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Charles Rector" <cr...@iexposure.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, November 26, 2002 8:10 AM
> Subject: Provider Classes
>
>
> > Is it possible to explicitly reference a provider class with an
> absolute
> > path? I am having classpath woes.
> >
> > A website I am developing with Enhydra 5.0 is dying when I include my
> site's
> > jar in multiserver's classpath (so SOAP will be able to find my
> services,
> > which exist as part of my site's code). Apparently this conflicts with
> the
> > jar which is specified in the classpath information for the site
> (Enhydra
> > 5.0 application) from within multiserver's admin (the same jar).
> Although I
> > have tried specifying the jar on the multiserver classpath only, and
> > removing the reference to it from the site's specialized classpath in
> the
> > multiserver admin -- I still encountered the same problem.
> >
> > The site works in concert with a standalone Java application, which
> has my
> > SOAP clients. When my site is dying, the standalone will run fine. But
> of
> > course, removing my site's jar from the multiserver classpath causes
> the
> > standalone to longer work, since it cannot find my SOAP services. So I
> can
> > get either my site or the standalone running, but not both at the same
> time.
> >
> > It looks like I basically just need some way to tell SOAP where my
> provider
> > classes are without having to tweak the classpath for multiserver. Has
> > anybody experienced a similar dilemma before? I've been stumped on
> this for
> > over 2 weeks now, and I'm starting to feel a bit discouraged. :-(
> >
> > --
> > Chuck Rector
> > Internet Exposure, Inc.
> > http://www.iexposure.com
> > crector@iexposure.com
> >
> > Web Development - Web Marketing - ISP Services
> > (612) 676-1946
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>

Re: Provider Classes

[Scott Nichol <sn...@scottnichol.com>]

Charles,

I am not sure how much help I will be, since I have not used Enhydra.  I
can only speak from the perspective of the J2EE specification.

Is your site deployed as a Web application, e.g. is it packaged as a war
file?  Apache SOAP, and the services deployed on it, are usually part of
a Web application or a separate Web application themselves.  In your
case, it seems you could either deploy Apache SOAP and your services as
part of the Web application for your site, or as a separate Web
application.  Your jar can (should?) be deployed within each Web
application, or once "globally".  I don't know how to translate this to
Enhydra terminology, nor do I know if there are bugs related to this
(Tomcat, for example, has had bugs with imperfect isolation of
webapp-specific classes).

Personally, I think it is better practice to put application code at the
webapp level, even if this means you load multiple copies for multiple
webapps.

I do not understand why your standalone apps break if your jar is not in
the multiserver classpath.  What should Enhydra's classpath have to do
with a standalone app running in a separate VM?  You can always specify
the standalone app's classpath with -classpath on the java command line,
anyway.

Scott Nichol

----- Original Message -----
From: "Charles Rector" <cr...@iexposure.com>
To: <so...@xml.apache.org>
Sent: Tuesday, November 26, 2002 8:10 AM
Subject: Provider Classes


> Is it possible to explicitly reference a provider class with an
absolute
> path? I am having classpath woes.
>
> A website I am developing with Enhydra 5.0 is dying when I include my
site's
> jar in multiserver's classpath (so SOAP will be able to find my
services,
> which exist as part of my site's code). Apparently this conflicts with
the
> jar which is specified in the classpath information for the site
(Enhydra
> 5.0 application) from within multiserver's admin (the same jar).
Although I
> have tried specifying the jar on the multiserver classpath only, and
> removing the reference to it from the site's specialized classpath in
the
> multiserver admin -- I still encountered the same problem.
>
> The site works in concert with a standalone Java application, which
has my
> SOAP clients. When my site is dying, the standalone will run fine. But
of
> course, removing my site's jar from the multiserver classpath causes
the
> standalone to longer work, since it cannot find my SOAP services. So I
can
> get either my site or the standalone running, but not both at the same
time.
>
> It looks like I basically just need some way to tell SOAP where my
provider
> classes are without having to tweak the classpath for multiserver. Has
> anybody experienced a similar dilemma before? I've been stumped on
this for
> over 2 weeks now, and I'm starting to feel a bit discouraged. :-(
>
> --
> Chuck Rector
> Internet Exposure, Inc.
> http://www.iexposure.com
> crector@iexposure.com
>
> Web Development - Web Marketing - ISP Services
> (612) 676-1946
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>

Re: Provider Classes

[Scott Nichol <sn...@scottnichol.com>]

Charles,

I am not sure how much help I will be, since I have not used Enhydra.  I
can only speak from the perspective of the J2EE specification.

Is your site deployed as a Web application, e.g. is it packaged as a war
file?  Apache SOAP, and the services deployed on it, are usually part of
a Web application or a separate Web application themselves.  In your
case, it seems you could either deploy Apache SOAP and your services as
part of the Web application for your site, or as a separate Web
application.  Your jar can (should?) be deployed within each Web
application, or once "globally".  I don't know how to translate this to
Enhydra terminology, nor do I know if there are bugs related to this
(Tomcat, for example, has had bugs with imperfect isolation of
webapp-specific classes).

Personally, I think it is better practice to put application code at the
webapp level, even if this means you load multiple copies for multiple
webapps.

I do not understand why your standalone apps break if your jar is not in
the multiserver classpath.  What should Enhydra's classpath have to do
with a standalone app running in a separate VM?  You can always specify
the standalone app's classpath with -classpath on the java command line,
anyway.

Scott Nichol

----- Original Message -----
From: "Charles Rector" <cr...@iexposure.com>
To: <so...@xml.apache.org>
Sent: Tuesday, November 26, 2002 8:10 AM
Subject: Provider Classes


> Is it possible to explicitly reference a provider class with an
absolute
> path? I am having classpath woes.
>
> A website I am developing with Enhydra 5.0 is dying when I include my
site's
> jar in multiserver's classpath (so SOAP will be able to find my
services,
> which exist as part of my site's code). Apparently this conflicts with
the
> jar which is specified in the classpath information for the site
(Enhydra
> 5.0 application) from within multiserver's admin (the same jar).
Although I
> have tried specifying the jar on the multiserver classpath only, and
> removing the reference to it from the site's specialized classpath in
the
> multiserver admin -- I still encountered the same problem.
>
> The site works in concert with a standalone Java application, which
has my
> SOAP clients. When my site is dying, the standalone will run fine. But
of
> course, removing my site's jar from the multiserver classpath causes
the
> standalone to longer work, since it cannot find my SOAP services. So I
can
> get either my site or the standalone running, but not both at the same
time.
>
> It looks like I basically just need some way to tell SOAP where my
provider
> classes are without having to tweak the classpath for multiserver. Has
> anybody experienced a similar dilemma before? I've been stumped on
this for
> over 2 weeks now, and I'm starting to feel a bit discouraged. :-(
>
> --
> Chuck Rector
> Internet Exposure, Inc.
> http://www.iexposure.com
> crector@iexposure.com
>
> Web Development - Web Marketing - ISP Services
> (612) 676-1946
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>

RE: Provider Classes

[Charles Rector <cr...@iexposure.com>]

I fixed my problem. Apparently I had everything in SOAP set up just fine,
and including my site's jar in the multiserver classpath was okay. I simply
had to include the multipart library in the multiserver classpath as well!
Now my site doesn't barf and my standalone app works great as well!
Excellent.

--
Chuck Rector
Internet Exposure, Inc.
http://www.iexposure.com
crector@iexposure.com

Web Development - Web Marketing - ISP Services
(612) 676-1946


--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>

RE: Provider Classes

[Charles Rector <cr...@iexposure.com>]

I fixed my problem. Apparently I had everything in SOAP set up just fine,
and including my site's jar in the multiserver classpath was okay. I simply
had to include the multipart library in the multiserver classpath as well!
Now my site doesn't barf and my standalone app works great as well!
Excellent.

--
Chuck Rector
Internet Exposure, Inc.
http://www.iexposure.com
crector@iexposure.com

Web Development - Web Marketing - ISP Services
(612) 676-1946