Re: [DotGNU]error installing dotgnu (DGEE)

[Chris Smith]

On Wednesday 14 May 2003 15:55, Gopal V wrote:

And I'm glad he did. :o)

> If memory serves me right, Szasz Pal wrote:

Hurrah!
Real user feedback.  Excellent!
I'm going to start building an FAQ.

> Hi , I'm CC'ing the list in the hope that this helps someone else
> as well ...
>
> > 1) it couldn't find libgc.so, so I added /usr/local/lib/pnet to
> > /etc/ld.so.conf
>
> Bug #1 ... that should be put in QUICKSTART ... that is because we
> started out with a shared .so installed from the pnet/libgc directory
> which would have been in {prefix}/lib ...

QUICKSTART updated (in the development branch dgee-0-1-5)

> > 2) it faild to compile correctly dgee, expat-devel was not installed
>
> expat-devel is needed for dgee ... after all it's an xml webservice
> platform , we can't do without a parser :-)

In fact, Goldwater requires expat otherwise it can't compile its configuration 
files.... so as soon as you've got goldwater compiled and installed you'll be 
okay from then on with the dgee.

> > 3) it gave an an error that pointers cannot be in case values,
> > in dgee-*/smgr/htmlTemplate.c line 371
>
> Curious ...

This _was_ a bug that has been fixed:
htmlTemplate.c: revision 1.4
date: 2003/04/22 13:08:55;  author: csmith;  state: Exp;  lines: +2 -2
Cast NULL to (int32) when checking value

> > But I still cannot test the examples
> > I modified the apache's conf file, and I try to access
> > http://localhost/stat.dgmx
> >
> > The response is "Service Temporary Unavailable...", and in
> > /var/log/httpd/error_log:

Classic mod_dgee is unable to access the Goldwater middleware.
Either it's not running or there are permission problems.

> > [Wed May 14 14:04:01 2003] [error] [client 127.0.0.1] (13)Permission
> > denied: Goldwater Initialisation Failed - Goldwater is not running
> >
> > I just started goldwater (i started dgeestart, is the same isn't it ?).
>
> You need to run goldwater and apache as the same user ... dgee uses
> good old unix IPC for communication with the middleware server (ie
> goldwater).
>
> All the connections are 0600 in masking out access from other users ..
> So you get a "Permission denied"...
>
> Following the quickstart , you might have to do some small things as well..
> The apache config directives "User nobody" and "Group nobody" will suit
> most people . Dgee user directives are set during compilation as
> ./configure parameters (./configure --with-username=<apache's user>
> --with-groupname=<apache's group>)...

Absolutely.

> > I ran dgeeenv.sh from command line, without it dgeestart doesn't even
> > started.
>
> dgeeenv.sh has the defines which is needed for all the DGEE tools depend
> upon ... Even installing a dgee webservice needs to run dgeeenv.sh first.

There are a bunch of environment variables that the DGEE needs.  Mainly 
GWCONFIG which points to the goldwater configuration file.  I don't generally 
like env variables, however there needs to be a way to run several goldwater 
instances on the same machine and even as the same user, so using an env 
variable is the most suitable approach.
The other DGEE_* environment variables are done as env variables because there 
are various shell scripts and tools that read them - they could be in a 
config file, but then it gets very complicated to process.

> I wonder if Chris would mind including an error message for the cases where
> $DGEE_HOME is undef ?

Good idea.

> Btw, I just managed to compile and install all the stuff needed to host
> a Webservice in my box from DGEE CVS right now ... so it's fairly stable
> today :-)

Was that the default CVS tree or the dgee-0.1.5 branch (the bleeding edge)?

> Folks, I would like to see csws2client (ie the automatic C# client
> generation tool) advance a bit further ... I haven't been able to work it
> out yet :-( I think you should use the URI class instead of inventing your
> parsing code ...

Minddog: This one's on you :o)
[Incidentally the URL/URI bit is grabbed from the namespace of the declared 
webservice, which is not correct - the namespace of the webservice is not 
necessarily related to where it is running....]

One of the things that we will be doing is creating some tools to allow c# 
client generation from a dgmx source, so client code can be generated for 
remote webservices regardless of the language the webservice is written in - 
this approach will work with python webservices.


Watchout for the new dgee release coming soon, with lovey admin features...


Good feedback.
Thanks.
Chris

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk