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 [EMAIL PROTECTED] Web Development - Web Marketing - ISP Services (612) 676-1946 > -----Original Message----- > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 26, 2002 8:38 AM > To: [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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 > > [EMAIL PROTECTED] > > > > Web Development - Web Marketing - ISP Services > > (612) 676-1946 > > > > > > -- > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
