Hi Al,

1. An off the cuff thought, possibly erroneous, but quick :-): It's
   conceivable that there is a second place from which the value of the
   JAVA_HOME environment variable is being read, other than from your own
   user environment.  It could conceivably be getting this value from
   another user's environment, or from some system configuration file.

a. Is Tomcat running under your own user account, or another
account? (Check this via 'ps -ef | grep catalina'; the first item in
the relevant entry will be the username under which Tomcat is running,
while the second item will be its process ID, relevant to response 2,
below.)

If it's running under another user account, you can log into that
user's account (or 'sudo su actual_username_here' to it) and check the
value of JAVA_HOME there ('echo $JAVA_HOME', much as you've done in
your account).

b. Is a value set for JAVA_HOME in any of the files in /etc/profile.d?

c. (You can skip this third point, as this is NOT relevant to the
issue you reported, which involved building CollectionSpace's
Application layer, but is mentioned here for completeness ... as a
different set of problems could result from it: Is a value explicitly
set for JAVA_HOME in any of the files in $CATALINA_HOME/bin, such as
setenv.sh or nuxeo.conf?  First, look in those two files; then 'grep
JAVA_HOME $CATALINA_HOME/bin', and ignore any comments or uses of
$JAVA_HOME as a variable name, etc.)

2. I've encountered this (a missing tomcat.pid file) on occasion,
   without having investigated its cause.

When that happens, as a fix, I've just killed the Tomcat process
('sudo kill actual_pid_here', where 'actual_pid_here' is the process
ID of that process, then restarted Tomcat, which re-creates that file.
(The tomcat.pid file itself is just a text file containing a process
ID.)

Aron

On Wed, Jul 31, 2013 at 2:04 PM, Al Bersch abersch@museumca.org wrote:

Hi Al,

The info line that says
[INFO]  We cannot execute /usr/lib/jvm/java-7-oracle/bin/java/bin/java
is interesting because it shows a malformed path to the java executable,
i.e. .../bin/java/bin/java. It should only be .../bin/java  AFAIK.
Your $JAVA_HOME env var looks correct. Nonetheless, could you print out the
JAVA_HOME variable you set in your environmental variables (maybe in
~/.bashrc if on a Linux OS)
I assume you were able to run the maven and ant commands on the services
layer code before running the application layer code?

I believe the message you got when attempting to shut down the app is fine.
It just means the Tomcat service was already shut down (force shutdown or
killed in some way) and behind a small file containing the ID of the process
running.

• Jesse

On Wed, Jul 31, 2013 at 5:04 PM, Al Bersch abersch@museumca.org wrote:

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Al,

1. An off the cuff thought, possibly erroneous, but quick :-): It's
   conceivable that there is a second place from which the value of the
   JAVA_HOME environment variable is being read, other than from your own
   user environment. It could conceivably be getting this value from
   another user's environment, or from some system configuration file.

a. Is Tomcat running under your own user account, or another
account? (Check this via 'ps -ef | grep catalina'; the first item in
the relevant entry will be the username under which Tomcat is running,
while the second item will be its process ID, relevant to response 2,
below.)

If it's running under another user account, you can log into that
user's account (or 'sudo su actual_username_here' to it) and check the
value of JAVA_HOME there ('echo $JAVA_HOME', much as you've done in
your account).

b. Is a value set for JAVA_HOME in any of the files in /etc/profile.d?

c. (You can skip this third point, as this is NOT relevant to the
issue you reported, which involved building CollectionSpace's
Application layer, but is mentioned here for completeness ... as a
different set of problems could result from it: Is a value explicitly
set for JAVA_HOME in any of the files in $CATALINA_HOME/bin, such as
setenv.sh or nuxeo.conf? First, look in those two files; then 'grep
JAVA_HOME $CATALINA_HOME/bin', and ignore any comments or uses of
$JAVA_HOME as a variable name, etc.)

2. I've encountered this (a missing tomcat.pid file) on occasion,
   without having investigated its cause.

When that happens, as a fix, I've just killed the Tomcat process
('sudo kill actual_pid_here', where 'actual_pid_here' is the process
ID of that process, then restarted Tomcat, which re-creates that file.
(The tomcat.pid file itself is just a text file containing a process
ID.)

Aron

On Wed, Jul 31, 2013 at 2:04 PM, Al Bersch abersch@museumca.org wrote:

Hi Al,

The info line that says
[INFO] We cannot execute /usr/lib/jvm/java-7-oracle/bin/java/bin/java
is interesting because it shows a malformed path to the java executable,
i.e. .../bin/java/bin/java. It should only be .../bin/java AFAIK.
Your $JAVA_HOME env var looks correct. Nonetheless, could you print out the
JAVA_HOME variable you set in your environmental variables (maybe in
~/.bashrc if on a Linux OS)
I assume you were able to run the maven and ant commands on the services
layer code before running the application layer code?

I believe the message you got when attempting to shut down the app is fine.
It just means the Tomcat service was already shut down (force shutdown or
killed in some way) and behind a small file containing the ID of the process
running.

• Jesse

On Wed, Jul 31, 2013 at 5:04 PM, Al Bersch abersch@museumca.org wrote:

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Aron, Jesse,

Thanks so much for your responses.

Aron, in answer to 1b, no, there is no value set for JAVA_HOME in
/etc/profile.d files (the files in there are bash_completion.sh and
Z97-byobu.sh and JAVA_HOME is not mentioned in either one).

Jesse, the JAVA_HOME variable set in ~/.bashrc is:    export
JAVA_HOME='/usr/lib/jvm/java-7-oracle'

(I used single quotes because double quotes didn't work in Maven3. Let me
know if I'm out of line here...)

As for the question of running maven and ant commands on the services layer,
yes, I ran both those commands successfully after following the instructions
in the documentation for

Installing 3.3 on Aptitude Compatible Linux Distributions. I then moved on
to "Creating Your Tenant," which brings me to another question - does it
matter where I put the source code for the Application and UI layers? And do
I need to check out the services layer source code, even though I already
installed it during the Installation phase (right?)?

And just in case it matters:
in answer to 1a, Tomcat is running under the user root, which I was using
to check out the layers, and perform the installation steps. Should I have
done that differently?
and as for 1c, JAVA_HOME is commented out for java 6 in nuxeo.conf, but no
other variable is set there.
Thanks again!
Al

Al Bersch
Digital Project Coordinator
Oakland Museum of California
1000 Oak Street, Oakland, CA 94607
abersch@museumca.org
510-318-8468

From: "Aron Roberts" aron@socrates.berkeley.edu
To: "Al Bersch" abersch@museumca.org
Cc: "talk" talk@lists.collectionspace.org
Sent: Wednesday, July 31, 2013 2:31:48 PM
Subject: Re: [Talk] error running mvn clean install -DskipTests

Having said this about 1.c, below, it's likely that 1.a. is also
irrelevant to your issue ... 1.b. might be worth looking into,
however.

From the error message, it looks like Maven might be using have a
different value for JAVA_HOME ... so check 1.b (whether a value for
JAVA_HOME is set in any files in /etc/profile.d), and then you can
report back, if that doesn't seem to be relevant.

On Wed, Jul 31, 2013 at 2:28 PM, Aron Roberts
aron@socrates.berkeley.edu wrote:

Hi all, thanks again.

Here's the response from
cd
grep JAVA_HOME.*

root@li551-203:~# grep JAVA_HOME .*
.bash_history:export JAVA_HOME="/usr/lib/jvm/java-7-oracle"
.bash_history:echo $JAVA_HOME
.bash_history:echo $JAVA_HOME
.bash_history:history | grep JAVA_HOME
.bashrc:export JAVA_HOME='/usr/lib/jvm/java-7-oracle'
.viminfo:~MSle0~/JAVA_HOME
.viminfo:?/JAVA_HOME

and

root@li551-203:~# *java -version
No command '*java' found, did you mean:
Command 'java' from package 'gcj-4.6-jre-headless' (main)
Command 'java' from package 'openjdk-6-jre-headless' (main)
Command 'java' from package 'openjdk-7-jre-headless' (universe)
Command 'java' from package 'default-jre' (main)
Command 'java' from package 'gcj-4.5-jre-headless' (universe)
*java: command not found
root@li551-203:~# *ls -al which java
No command '*ls' found, did you mean:
Command 'als' from package 'atool' (universe)
Command 'ls' from package 'coreutils' (main)
Command 'jls' from package 'sleuthkit' (universe)
Command 'hls' from package 'hfsutils' (main)
Command 'ols' from package 'speech-tools' (universe)
Command 'bls' from package 'bacula-sd' (main)
Command 'tls' from package 'python-tlslite' (universe)
Command 'fls' from package 'sleuthkit' (universe)
Command 'ils' from package 'sleuthkit' (universe)
*ls: command not found

thanks!

Al Bersch
Digital Project Coordinator
Oakland Museum of California
1000 Oak Street, Oakland, CA 94607
abersch@museumca.org
510-318-8468

From: "Aron Roberts" aron@socrates.berkeley.edu
To: "Jesse Martinez" mjesse@gmail.com, "Al Bersch" abersch@museumca.org
Cc: "talk" talk@lists.collectionspace.org
Sent: Wednesday, July 31, 2013 2:44:17 PM

Subject: Re: [Talk] error running mvn clean install -DskipTests

Thanks, Jesse!

It'd definitely be useful to see any and all JAVA_HOME entries in your
$HOME/.bashrc and/or $HOME/.bash_profile file(s); e.g.

cd
grep JAVA_HOME .*

(The full files might likely have passwords, etc. so that you may not
want to send those entire files.)

Also: what do you get when you run the following?

• java -version
• ls -al which java    (note the 'backticks')

On Wed, Jul 31, 2013 at 2:31 PM, Jesse Martinez mjesse@gmail.com wrote:

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Aron

P.S. One more thing I'm noticing in the output from running
that 'Ant' command - which runs successfully on my system -
this appears:

parsing buildfile
jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/antlib.xml
with
URI = jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/antlib.xml
from a zip file

While nearly all of what Ant is doing is simple file copying,
this stood out.

Maybe this could be Ant trying to read a JAR file - possibly a file
that contains code for one of its external tasks, 'hostinfo' - and failing,
because its path to the 'jar' command (one of the many command
line utilities included with Java) is incorrect, possibly due to that
JAVA_HOME snafu.  That's the best I can come up with so far.

If we can't get this quickly solved any other way, you might try opening
war-entry/build.xml, and in the following block:

 <target name="post_build_tasks"
     description="Various post-build tasks"
     depends="deploy_cspace_config, deploy_nightly_config, retrieve_jar">
 </target>

delete 'deploy_nightly_config,' (including the trailing comma) from the
'depends' line above, and see if the error persists.  That should remove
Ant's need for the 'hostinfo' task.

On Wed, Jul 31, 2013 at 3:00 PM, Al Bersch abersch@museumca.org wrote: