Deploying Services

[Dan Galewsky]

Bill --

After reading your earlier email - I decided I should not exit from the osgi command prompt after I start the osgi container (which I had been doing). 

I had thought that the run.sh command used to start the osgi container started an osgi daemon process - but that seems to not be the case (??).

Now when I try to deploy a service - I get the following 404 error in the error dialog box in the GUI.

HTTP Status 404 - /org.duracloud.services.admin_2.1.1/services/install
type Status report
message /org.duracloud.services.admin_2.1.1/services/install
description The requested resource (/org.duracloud.services.admin_2.1.1/services/install) is not available.

Here are the lines from my config.properties file relevant to service deployment. 

###

# defines duraservice elements

###

duraservice.primary-instance.host=duracloud.lib.utexas.edu

duraservice.primary-instance.services-admin-port=8089

duraservice.primary-instance.services-admin-context=org.duracloud.services.admin_2.1.1

duraservice.user-storage.host=duracloud.lib.utexas.edu

duraservice.user-storage.port=80

duraservice.user-storage.context=durastore

duraservice.user-storage.msg-broker-url=tcp://duracloud.lib.utexas.edu:61617

duraservice.service-storage.host=duracloud.lib.utexas.edu

duraservice.service-storage.port=80

duraservice.service-storage.context=durastore

duraservice.service-storage.username=admin

duraservice.service-storage.password=XXX

duraservice.service-storage.space-id=duracloud-2-1-1-service-repo

duraservice.service-storage.service-xml-id=duracloud-2-1-1-service-repo.xml

I can see the jar files and XML files in the space called duracloud-2-1-1-service-repo.  I looked at the duracloud-2-1-1-service-repo.xml and it looks more or less reasonable.

So - there is still something not quite configured properly. 

Thanks for your help.

--Dan 

[Bill Branan]

Hi Dan,

You are correct to not exit from the OSGi command prompt, as it is simply running as an interactive process, not kicking off a daemon. If you're running it on a linux system, you can use the nohup command with the & parameter (e.g. "nohup run.sh &") to run it as a daemon, if you wish. For the moment, the fact that it provides you with an interactive prompt is useful.

I assume that you're following the instructions from #4 on this page to start up your OSGi container: https://wiki.duraspace.org/display/DURACLOUDDOC/Deploying+DuraCloud+from+Binaries. Paying special attention to #4 part g, when the OSGi container is initially started, you should use the "ss" command to display the list of bundles deployed. This list should contain 50 items, one of which should be the duracloud.services.admin bundle.

I don't see any problems in your config. I assume that http://duracloud.lib.utexas.edu/durastore/duracloud-2-1-1-service-repo/duracloud-2-1-1-service-repo.xml resolves to your service XML file.

Bill

--Dan 

--
You received this message because you are subscribed to the Google Groups "DuraCloud Dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/duracloud-dev/-/R41DgY7CC8UJ.
To post to this group, send email to duracl...@googlegroups.com.
To unsubscribe from this group, send email to duracloud-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/duracloud-dev?hl=en.

[Dan Galewsky]

Bill -- I have included the list returned from the ss command. 

It does contain 50 items including org.duracloud.services.admin.

Are the services listed as RESOLVED - rather than ACTIVE a problem?

And - yes 

http://duracloud.lib.utexas.edu/durastore/duracloud-2-1-1-service-repo/duracloud-2-1-1-service-repo.xml

does resolve to an XML file.

Does the fact that this XML file has unresolved variables indicate a problem ? i.e. 

<systemConfig>

<property id="0" name="svcLaunchingUser" value="$SVC-LAUNCHING-USER"/>

<property id="0" name="duraStoreHost" value="$DURASTORE-HOST" defaultValue="localhost"/>

<property id="0" name="duraStorePort" value="$DURASTORE-PORT" defaultValue="8080"/>

<property id="0" name="duraStoreContext" value="$DURASTORE-CONTEXT" defaultValue="durastore"/>

<property id="0" name="username" value="$DURASTORE-USERNAME" defaultValue="no-username"/>

<property id="0" name="password" value="$DURASTORE-PASSWORD" defaultValue="no-password"/>

</systemConfig>

And one other odd thing I noticed this morning - in the error dialog box - where Duracloud is reporting the problem deploying the service - it says 

Apache Tomcat/5.5.23

This is odd because we are running Tomcat 6. Could there be some config variable that is pointing off to some other system?

Thanks

--Dan Galewsky

---- Output from OSGI ss command ----

Framework is launched.

id      State       Bundle

0       ACTIVE      org.eclipse.osgi_3.7.0.v20110613

1       ACTIVE      org.springframework.osgi.web.extender_1.2.0

2       ACTIVE      org.duracloud.services.admin_2.1.1

3       RESOLVED    org.duracloud.services.tomcatconfig_2.1.1

                    Master=18

4       ACTIVE      org.springframework.web.servlet_2.5.6

5       ACTIVE      org.springframework.context_2.5.6

6       ACTIVE      org.springframework.transaction_2.5.6

7       ACTIVE      org.springframework.jdbc_2.5.6

8       ACTIVE      org.springframework.core_2.5.6.A

9       ACTIVE      org.springframework.context_2.5.6.A

10      ACTIVE      org.springframework.beans_2.5.6.A

11      ACTIVE      org.springframework.beans_2.5.6

12      ACTIVE      org.springframework.aop_2.5.6.A

13      ACTIVE      org.apache.felix.fileinstall_1.2.0

14      ACTIVE      com.springsource.javax.el_2.1.0

15      ACTIVE      com.springsource.javax.persistence_1.0.0

16      ACTIVE      com.springsource.org.aopalliance_1.0.0

17      ACTIVE      org.springframework.osgi.catalina.osgi_5.5.23.SNAPSHOT

18      ACTIVE      org.springframework.osgi.catalina.start.osgi_1.0.0

                    Fragments=3

19      ACTIVE      org.springframework.osgi.web_1.2.0

20      ACTIVE      org.springframework.web_2.5.6.A

21      ACTIVE      org.springframework.web.servlet_2.5.6.A

22      ACTIVE      org.springframework.osgi.core_1.2.0

23      ACTIVE      org.springframework.osgi.extender_1.2.0

24      ACTIVE      org.springframework.osgi.io_1.2.0

25      ACTIVE      org.duracloud.services.util_2.1.1

26      ACTIVE      org.duracloud.common_2.1.1

27      ACTIVE      org.duracloud.services.computeservice_2.1.1

28      ACTIVE      org.duracloud.services.common_2.1.1

29      ACTIVE      com.springsource.org.apache.commons.httpclient_3.1.0

30      ACTIVE      com.springsource.org.apache.commons.codec_1.3.0

31      ACTIVE      org.apache.felix.configadmin_1.0.10

32      ACTIVE      ch.qos.logback.core_0.9.21

33      ACTIVE      slf4j.api_1.6.0

34      ACTIVE      ch.qos.logback.classic_0.9.21

35      ACTIVE      jcl.over.slf4j_1.6.0

36      ACTIVE      log4j.over.slf4j_1.6.0

37      ACTIVE      org.springframework.core_2.5.6

38      ACTIVE      com.springsource.org.apache.commons.logging_1.1.1

39      RESOLVED    com.springsource.slf4j.log4j_1.5.0

                    Master=41

40      ACTIVE      com.springsource.org.apache.log4j_1.2.15

41      ACTIVE      com.springsource.slf4j.api_1.5.0

                    Fragments=39

42      ACTIVE      com.springsource.javax.jms_1.1.0

43      ACTIVE      com.springsource.javax.transaction_1.1.0

44      ACTIVE      com.springsource.com.thoughtworks.xstream_1.3.0

45      ACTIVE      com.springsource.javax.xml.stream_1.0.1

46      ACTIVE      com.springsource.org.xmlpull_1.1.3.4-O

47      ACTIVE      com.springsource.org.apache.commons.fileupload_1.2.0

48      ACTIVE      com.springsource.javax.portlet_1.0.0

49      ACTIVE      com.springsource.javax.servlet_2.5.0

50      ACTIVE      com.springsource.org.apache.commons.io_1.4.0

[Bill Branan]

Hey Dan,

The list of services looks right, and the fact that a few are resolved rather than active is fine, those just indicate what OSGi calls bundle fragments, meaning that they are not stand-alone bundles but instead are used to extend other bundles. 

Also, the variables in the service xml file are fine, those variables are resolved by DuraService. It sounds like the connection from DuraService to the service repository is fine, but the issue is in the connection between DuraService and the services.admin bundle running in the OSGi container.

Your final note about the tomcat error showing the wrong version of Tomcat is concerning. According to your config, DuraService should be making calls to the services.admin bundle at duracloud.lib.utexas.edu on port 8089. I'm assuming that this port is open. If the calls are coming through, you should be seeing logs in your OSGi container command prompt as the service is deployed. Otherwise, you should be seeing errors in your DuraService log file. You may need to update the logging config to set it to log at the DEBUG level. At that point, you should be able to see in the DuraService log where the calls to services.admin are going, and what errors are coming back. That will likely be your best clue as to what the issue is here.

Bill

--

You received this message because you are subscribed to the Google Groups "DuraCloud Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/duracloud-dev/-/hlMM0JtoZ3oJ.

[Andrew Woods]

Dan,
According to your config, both of the following should render html in
your browser?
http://duracloud.lib.utexas.edu:8089/org.duracloud.services.admin_2.1.1
http://duracloud.lib.utexas.edu:8089/org.duracloud.services.admin_2.1.1/services/list

If they do not, then services-admin did not come up properly. There
may be clues in the logfile defined by $BUNDLE_HOME/logback.xml (see
your run.sh).
If they do, then feel free to pass along your OSGi logfile.
Andrew

On Tue, Dec 18, 2012 at 12:36 PM, Dan Galewsky <dgal...@gmail.com> wrote: