If I could just get the stupid thing to build

Time for a new Alfresco on Glassfish walkthrough

My Alfresco on Glassfish Walkthrough is over a year old now and is creaking at the seams a little so I plan to update it. Feel free to comment here on what the new walkthrough should cover, Glassfish v2.1 or v3? Solaris or OpenSolaris? Linux or Windows? Which DB (just MySQL or some other OSDB)?

In fact feel free to comment on anything you would like to see to do with running Alfresco (or any other (E)CMS app) on Sun gear.

Original blog entry: http://blogs.sun.com/mandy/entry/alfresco_on_glassfish_on_opensolaris

Cheers

Amanda

Posted at 11:39AM Nov 11, 2009 by MandyWaite in Open Source  |  Comments[2]

autoconf weirdness

configure.ac files (configure.in in the old days) are used as input to autoconf which miraculously (it's all miraculous to me) expands the macros in the configure.ac file and creates a runnable configure shell script. Autoconf macros may be system dependent so if you decide to regenerate a configure script, it's the job of autoconf, in conjunction with aclocal, to locate all of the macro definitions that it's going to need to get the job done. These macro definitions may be supplied by the local installation of autoconf, by other packages via aclocal or actually supplied by the package you are building in a file named acinclude.m4

Due to some changes in the way Lighttpd is built I found that for Lighttpd 1.4.23 in WebStack we had to regenerate the configure script, I did this using the autogen.sh script that ships with the lighttpd source code. autogen.sh calls libtool, aclocal, automake, autoconf and autoheader. On Solaris 10 autoconf generated an error:

configure.ac:67: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

But AC_DEFINE is a standard autoconf macro so why can't it be found? We dug around and found mention of it being to do with pkg-config but couldn't work out why that would be. So We stripped down the lighttpd configure.ac bit by bit and found that the problem went away when we removed the lines referencing a macro named PKG_CHECK_MODULES. The file aclocal.m4 in the lighttpd build directory contains any additional macros required by autoconf to process configure.ac and is generated by aclocal. The lighttpd source distribution includes the aclocal.m4 file that was used to create the original configure script, but when you run aclocal, a new aclocal is generated from macros that have been registered with aclocal on the local system. On this system, after running aclocal, aclocal.m4 didn't contain a macro named PKG_CHECK_MODULES :o/

Further research showed that PKG_CHECK_MODULES is usually supplied in a file named pkg.m4 which is installed as part of pkg-config. It usually installs to /usr/share/aclocal which is the default location used by aclocal to locate macros. In this case though we were using a tool set specifically created by the WebStack team for building WebStack on Solaris 10. In this tool set (wstools),  aclocal lives in /export/wstools/bin and it looks for macro definitions in /export/wstools/share/aclocal. wstools doesn't include pkg-config so there's no pkg.m4. That explains why it couldn't find the PKG_CHECK_MODULES macro, but why the error about AC_DEFINE?

In configure.ac you'll find:

  if test "x$FAM_LIBS" = x; then
    PKG_CHECK_MODULES(FAM, gamin >= 0.1.0, [
      AC_DEFINE([HAVE_LIBFAM], [1], [libfam])
      AC_DEFINE([HAVE_FAM_H], [1], [fam.h])
    ])
  fi

So you can kind of see why the AC_DEFINEs passed to the PKG_CHECK_MODULES macro could be affected, but autoconf indicated that the error came from a line of code not related to PKG_CHECK_MODULES, i.e.:

AC_CHECK_MEMBER(struct tm.tm_gmtoff,[AC_DEFINE([HAVE_STRUCT_TM_GMTOFF],[1],[gmtoff
in struct tm])],,[#include <time.h>])

Here AC_DEFINE is used with another standard autoconf macro (AC_CHECK_MEMBER) and if you look at the generated configure script you find:

if test "x$ac_cv_member_struct_tm_tm_gmtoff" = x""yes; then

cat >>confdefs.h <<\_ACEOF
#define HAVE_STRUCT_TM_GMTOFF 1
_ACEOF

fi

Which shows that it didn't actually fail where it said it did. Turns out the time it failed to process AC_DEFINE were where it was used with PKG_CHECK_MODULES. The error from autoconf actually referenced the first use of AC_DEFINE and not where it failed. Best of all, rather than emit a warning about PKG_CHECK_MODULES being missing, it just adds this to the configure script:

  if test "x$FAM_LIBS" = x; then
    PKG_CHECK_MODULES(FAM, gamin >= 0.1.0,
      AC_DEFINE([HAVE_LIBFAM], [1], [libfam])
      AC_DEFINE([HAVE_FAM_H], [1], [fam.h])
    )
  fi

Which is the un-expanded macro calls from configure.ac. These aren't valid shell commands, so the generated configure script will fail. In this case the best way to fix the problem is by adding pkg-config to the WebStack build tool set.  I've also heard that this problem can occur on systems with older versions of pkg-config, I guess that they may not define a PKG_CHECK_MODULES with the signature required by the configure.ac script.

Posted at 06:43PM Nov 05, 2009 by MandyWaite in Open Source  |  Comments[0]

Installing OpenSolaris packages from /contrib and /pending

The OpenSolaris /contrib package repository has a whole bunch of packages contributed by members of the OpenSolaris community or just by those who had a particular need for a certain package and who decided to submit it themselves.

You can install any of these packages either using the pkg command or via the package manager, you can even just go to the /contrib repository's catalog page and click on the 'install' link for the package(s) that you want to install.

To set up /contrib as a valid publisher for use with the package manager or the pkg command do the following as a user with the root role (or Software Installation profile):

pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

Or you can add /contrib via the package manager through the File -> Manage Repositories pull down. If installing from the "install" link at http://pkg.opensolaris.org/contrib/en/catalog.shtml  the package manager will automatically add /contrib to the list of publishers.

To install packages using pkg, do the following:

pfexec pkg refresh

pfexec pkg install <package name>

You don't have to run 'pkg refresh' before installing every package, but it is probably best to do it reasonably regularly just to make sure that pkg has an up to date view of the repositories that it knows about.

There is also a /pending repository which is used to stage packages for testing while they are being made ready for promotion to /contrib. I wouldn't recommend arbitrarily using packages from /pending but you may want to provide feedback on a package, or as in the case with the ruby-mysql package, it maybe that the owner has suggested that you get it from /pending due to some issue getting it into /contrib.

To setup /pending as a publisher, you do much the same as you do for /contrib:

pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending  pending

Or use the package manager File -> Manage Repositories menu.

To list the repositories that pkg knows about, run:

% pkg publisher 

PUBLISHER                             TYPE     STATUS   URI

opensolaris.org          (preferred)  origin   online   http://pkg.opensolaris.org/
contrib                               origin   online   http://pkg.opensolaris.org/contrib/
pending                               origin   online   http://jucr.opensolaris.org/pending/
mypkgs                                origin   online   http://localhost:80/
webstack                              origin   online   http://pkg.opensolaris.org/webstack/

If you have both /contrib and /pending added as publishers, when you install packages you'll need to qualify the package name with the name of the publisher from which you want to install it as follows:

pfexec pkg install pkg://pending/ruby-mysql

Which will install the 'ruby-mysql' package from the publisher name pending. Note that this is the publisher name, not the URI of the repository.

In the list of repositories above are a couple of other repositories that we've not talked about. The /webstack repository has packages that the WebStack team feel might be useful, but for which they are unable to offer support. This has packages for Web Tier applications such as Varnish and Nginx. We also sometime publish packages that are in the process of being integrated into OpenSolaris but are not yet available in the main repositories. The mypkgs repository is a repository local to our test system. It is very easy to set up a build environment for building your own packages from Spec files and then to publish them to a local repository. If you're going to do that though, you might as well publish them to /contrib via SourceJuicer.

Here's some other links that you might find useful:

Spec Files Extra is a project centered around the pkgbuild tool that builds Solaris SVR4 and/or IPS packages from spec files (and which is used by SourceJuicer)

The Genunix site has a page describing how to setup a SourceJuicer like environment

If you'd rather not get involved in submitting spec files to SourceJuicer but would like to see a package in OpenSolaris, drop us an email at sw-porters-discuss@opensolaris.org.

Posted at 11:26AM Oct 29, 2009 by MandyWaite in Open Source  |  Comments[0]

Nagios, Octave and SilverStripe in OpenSolaris

Several interesting packages were published to the OpenSolaris /contrib repository yesterday. They include Octave, SilverStripe and the 3 packages that make up Nagios. 

Nagios is a leading Open Source infrastructure monitoring tool that can monitor networks, hosts and even services, in fact it can monitor pretty much anything and it being Open Source it's fairly straightforward to add your own plugins. The main Nagios package is simply named nagios and delivers version 3.0.6 currently. In addition there is the nagios-plugins package which you'll install on systems that you want to monitor. A third package is nrpe (Nagios Remote Plugin Executor), which allows a centralised deployment of Nagios to execute and monitor plugins on other systems.

Octave is a GNU project, it's a high level language and runtime whose main use is for numerical computations. It's mainly command line driven, but can hook up with the likes of gnuplot in order to present graphs and other visual forms of mathematical data. I've tested it and it looks like it could be really useful for someone say, studying for a maths degree... like me for instance :o)

SilverStripe is a popular Open Source Content Management System, it's one of a number of such applications that OpenSolaris users have been clamouring for. Interestingly we did have some problems getting it to play nicely with MySQL 5.1 on OpenSolaris. When you are setting up the MySQL database prior to configuring SilverStripe modify the MySQL SMF service as follows:

svccfg -s mysql:version_51 setprop mysql/enable_64bit=true
svcadm refresh mysql:version_51
svcadm restart mysql:version_51

You'll either need to do this as root or as a user with the root role. These changes cause MySQL 5.1 to run in 64-bit mode.

You can install any of these packages either using the pkg command or via the package manager, you can even just go to the /contrib repository's catalog page and click on the 'install' link for the package(s) that you want to install.

To set up /contrib as a valid publisher for use with the package manager or the pkg command do the following as a user with the root role (or Software Installation profile):

pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

Or you can add /contrib via the package manager through the File -> Manage Repositories pull down. If installing from the "install" link at http://pkg.opensolaris.org/contrib/en/catalog.shtml  the package manager will automatically add /contrib to the list of publishers.

To install packages using pkg, do the following:

pfexec pkg refresh

pfexec pkg install <package name>

These packages are great additions to the growing list of packages available via the /contrib repository. If you would like to contribute a package to /contrib visit the SourceJuicer page on OpenSolaris.org. If you'd rather not get involved in submitting spec files to SourceJuicer but would like to see a package in OpenSolaris, drop us an email at sw-porters-discuss@opensolaris.org.

Posted at 05:47PM Oct 28, 2009 by MandyWaite in Open Source  |  Comments[0]

Rake should be on the default PATH...

I can convince myself of anything. When we updated from RubyGems 0.9.4 to 1.3.5 I decided that it was ok for the 'rake' command to be in the $GEM_HOME/bin which then translated to /var/ruby/1.8/gem_home/bin. I justified it because users could run 'gem env', look at the "EXECUTABLE DIRECTORY" and see that they had to add /var/ruby/1.8/gem_home/bin to their $PATH env var. Having had to install and then run rake several times on different systems over the last few days I can see that this is wrong. I want to 'gem install rake' and then run 'rake <some rake task>' without the need to update my PATH. I'm certain that others will agree that this is how it should be.

I could easily change the way that we build RubyGems such that the "EXECUTABLE DIRECTORY" defaults to /usr/bin but I have no way of being certain that when the end user runs 'gem install <some gem with an executable>' that /usr/bin will actually be writable even by root (or the root role as used by pfexec). We have the Rails package in the /contrib repository that also delivers the Rake gem. This package installs the 'rake' executable to /usr/bin, but it's a bit much to ask you to install Rails just to get Rake. I seem to have the following options:

1. With the SUNWruby18 package on OpenSolaris, provide wrapper scripts in /usr/bin for the popular gems that deliver executables. These would emit a message saying to install the require Gem should it not already be installed and run as normal if it is. This has a few corner cases that have to be considered
2. Provide a /contrib package that provides wrapper scripts for popular gems which would work as described in (1)
3. Change "EXECUTABLE DIRECTORY" to /usr/bin and modify RubyGems to detect the writability of /usr/bin. It does this by default but would end up installing any affected gems in root's ~/.gem directory.

I favour option 3, but only if it can be done without significant changes to RubyGems.

Posted at 01:19PM Oct 14, 2009 by MandyWaite in Open Source  |  Comments[2]

Other packages in /contrib

Just following on from my last post, we've also added FreeImage to the OpenSolaris /contrib repository. This is pretty useful as FreeImage is used by the image_science ruby gem for manipulating images, particularly creating Thumbnails from uploaded images. FreeImage can be difficult to build on OpenSolaris and the 'freeimage' OpenSolaris package is fully built and includes both a static library and a shared library that can be used to build against when developing applications. You can install this package with the following commands (the first isn't needed if you've already added /contrib as a publisher) :

% pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

% pfexec pkg refresh

% pfexec pkg install freeimage

If you then install the image_science gem (along with the RubyInline gem that is used to dynamically build the image_science native library) you won't need to provide additional flags in order to locate the FreeImage library.

FreeImage and ImageScience are used in the Apache Olio Rails applications

Our group also recently integrated WordPress into /contrib (as 'wordpress'). Installing this package will pull in all of the Apache and PHP packages required to run WordPress. It leaves the DB to you as you might chose to run MySQL locally or on a completely different system. It actually really makes installing WordPress and getting up and running really easy. We are also working on adding Drupal, Moveable Type, Joomla!, SilverStripe, Cacti, Ganglia, Nagios, the GNU Linear Programming Kit and Octave.

Posted at 11:46AM Sep 25, 2009 by MandyWaite in Open Source  |  Comments[0]

Apache Olio: Web 2.0 toolkit for Java EE

This week saw the Apache Olio project release the code for it's Java EE version adding to the versions already available for PHP and Rails. 

If you know Apache Olio and want to know more about the specifics of the Java EE version then I'll cover them first, if you want to know more about Apache Olio in general, read on.

To run the Java EE version of Olio, you'll need:

• Java SE 5 or 6
• Java EE 5 compliant application server (tested so far with GlassFish v2)
  
• A Java Persistence API (JPA) provider (Eclipselink is the JPA provider packaged with GlassFish v2)
• MySQL Database (any DB could be used but we have scripts and instructions for MySQL)

Some of the technologies that the Java EE version features:

• JPA for the Object-Relational persistence solution
• AJAX 
• Rest based Services (partially implemented)
• JMaki widgets wrappers for Yahoo and dojo widgets

In planning are the following changes/features:

What is Apache Olio?

Apache Olio is a Web 2.0 toolkit, basically it's a Web 2.0 application and a load generator. You deploy the application to a configuration that you want to test, fire up the load generator, drive load to the application and then analyze the results. The application isn't that fussy about what it runs on, for the Java EE app you need a Java EE Web container (Glassfish or Tomcat for example), you also need a Database and a schema is provided that can be used to set that up. You need a filestore and you need a Web Server to act as a remote Web Service (for looking up geolocations). 

Apache Olio uses Faban to drive load along with a custom Faban driver. Faban is a benchmark driver framework and harness that is designed to allow you to model the usage of your application and drive load for 1000s of simulated users. It also can be used to manage the runtime environment and it gathers the results from test runs.

Once you've deployed the application you can load it up with dummy users and events (it's a Social Networking app) and use the driver to simulate load. At the end of a test run, you get all of the data from the run presented to you in graphical form (depending on the platform). I spend a vast amount of time using Olio and Faban and can't recommend them enough.

Kim is the lead developer of the Java EE version of Apache Olio and he has a blog entry that goes into lots of detail on how Apache Olio Java EE works and what it looks like.

Posted at 05:04PM May 14, 2009 by MandyWaite in Open Source  |  Comments[0]

Ruby 1.8.7 and RubyGems 1.3.1 on OpenSolaris

Last week, all of the work that Chris Zhu, Prashant Srinivasan and I did on integrating Ruby 1.8.7 p72 and RubyGems 1.3.1 into OpenSolaris bore fruit as the packages became available in the /dev repository of OpenSolaris.

You can still use Ruby 1.8.6 as that's the version that was in the 2008.11 release of OpenSolaris, these packages won't get promoted to the main repository until the next release of OpenSolaris in May/June. 

In order to upgrade to Ruby 1.8.7 in OpenSolaris in the meantime you need to upgrade all of the packages so that they are at the same level. Once you have upgraded you'll no longer have Ruby 1.8.6 available to you, so make sure that's really what you want to do. Prashant wrote a brief guide on how to update Ruby in OpenSolaris a while back and you can find that here.

We'd be happy to receive any feedback on your experiences in upgrading and your thoughts on what you really would like to see for Ruby and RubyGems in OpenSolaris. As Ruby/RubyGems is part of Sun WebStack you can ask questions and post comments on the webstack-discuss@opensolaris.org  alias (you need to subscribe first at http://opensolaris.org) or you can post a comment on either of our blogs.

Posted at 10:29AM Mar 25, 2009 by MandyWaite in Open Source  |  Comments[1]

Alfresco on Glassfish (short version)

I posted a complete walkthrough on how to get Alfresco up and running on Glassfish earlier . Here's a version for those who don't need all the detail.

Glassfish has an undocumented property that when used in conjunction with the Classloader Delegate feature will allow MyFaces libraries to be loaded before the JSF libraries. You set both of these in the server specific deployment descriptor which is named sun-web.xml and which lives in the WEB-INF directory of the War file. The complete file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
 <class-loader delegate="false"/>
 <property name="useMyFaces" value="true"/>
</sun-web-app> 

So create the file, place it in a directory named WEB-INF and then add it to the alfresco.war file:

$ jar uvf alfresco.war WEB-INF/sun-web.xml
adding: WEB-INF/sun-web.xml(in = 316) (out= 236)(deflated 25%)

Then deploy the alfresco.war file. If you've done everything else that's needed, you should be able to fire up a browser and connect to Alfresco at http://localhost:8080/afresco

Posted at 11:26PM Oct 10, 2008 by MandyWaite in Open Source  |  Comments[4]

Alfresco on Glassfish

This walkthrough is for OpenSolaris, it was made on the b98 development build but I'd expect it to work on the release version of 2008.05. It probably works on all other platforms as well with some changes to the pathnames and some of the commands. I'll work on something similar for Solaris, Ubuntu and for Windows.

I've posted a shorter version for those who have previously tried to get it working but were just missing the vital ingredient.

Initial Setup

I'm going to assume you are doing this as a non-root user. If you do this as root, just drop the pfexec statement from any commands you issue.

First install Glassfish and MySQL:

$ pfexec pkg refresh 
$ pfexec pkg install glassfishv2 
$ pfexec pkg install SUNWmysql5

Unlike with the best tutorials, I won't first remind you to turn your system on or not to install the packages if they are already installed.

OpenSolaris has this nifty feature called SMF but we haven't yet managed to hook the installation of packages up such that Services are automatically registered with it yet although that should be there in the November release. For now run the following to register it:

$ pfexec svccfg import /var/svc/manifest/application/database/mysql.xml

and then start the MySQL service:

$ pfexec svcadm enable mysql

This will do all of the work required to get MySQL up and running for the first time. Now create a DB and a user to access it with.

$ /usr/mysql/50/bin/mysqladmin -u root create alfresco

$ /usr/mysql/50/bin/mysql -u root

mysql> grant all privileges on alfresco.* to 'alfresco'@'%' identified by 'alfresco';
Query OK, 0 rows modified (0.00sec) 

mysql> grant all privileges on alfresco.* to 'alfresco'@'localhost' identified by 'alfresco';
Query OK, 0 rows modified (0.00sec) 

Now setup a Glassfish domain:

$ pfexec /usr/sbin/asadmin create-domain --adminport 4848 domain1

You need a JDBC MySQL driver:

$ wget http://mysql.osuosl.org/Downloads/Connector-J/mysql-connector-java-5.1.6.tar.gz

The URL used for the MySQL JDBC driver is just one of many mirrors. You might be better off going to http://dev.mysql.com/downloads/connector/j/5.1.html and choosing where to get it from.

Unpack this somewhere and copy mysql-connector-java-5.1.6-bin.jar to the Glassfish domain's lib directory:

$ pfexec cp mysql-connector-java-5.1.6-bin.jar /var/appserver/domains/domain1/lib

While you are doing this you may as well create an alfresco directory in the same place, you'll need it later.

$ pfexec mkdir /var/appserver/domains/domain1/lib/classes/alfresco

Alfresco War file and configuration

This testing was done with Alfresco labs 3b, it should work with other versions, but if it doesn't post a comment on this blog and I'll look into it.

Next we'll need the Alfresco War file, which you can probably get like this:

$ wget http://us.dl.alfresco.com/build-1164/alfresco-labs-war-3b.tar.gz

But as that looks like a URI than might have been created by SkyNet a machine, you may need to fallback to going here:

http://wiki.alfresco.com/wiki/Installing_Labs_3#Linux_download_and_installation

Once you have it, extract the bundle somewhere, you won't need it after the setup is finished.

You now need to setup the Alfresco bits that aren't contained in the WAR file. From the directory in which you unpacked the Alfresco bundle, copy the entire contents of the extensions directory to the directory you created earlier:

$ pfexec cp -r extensions/* /var/appserver/domains/domain1/lib/classes/alfresco

You don't want to copy over the extensions directory itself, just it's contents (extension and messages directories).

Alfresco needs somewhere to keep all of it's documents and indexes. This is usually named alf_data, if you don't specify a path to alf_data or the path doesn't exist it will create one for you... somewhere. Let's not leave things to chance and create one and then configure Alfresco to find it:

$ pfexec mkdir /var/alfresco/alf_data

Now cd to /var/appserver/domains/domain1/lib/classes/alfresco/extension and modify the config files so that Alfresco can find alf_data and can find the database. The files that need changing are:

custom-repository.properties 

custom-hibernate-dialog.properties

In custom-repository.properties do the following:

Uncomment the dir.root line and change it's path to /var/alfresco/alf_data

#dir.root=/srv/alfresco/alf_data

becomes:

dir.root=/var/alfresco/alf_data

Uncomment the db.username and db.password lines

#db.username=alfresco
#db.password=alfresco 

becomes:

db.username=alfresco
db.password=alfresco 

The last part of the file has sections for specific databases, by default it's setup to use Derby. Comment out the lines for derby and uncomment the lines for MySQL

db.driver=org.apache.derby.jdbc.EmbeddedDriver
db.url=jdbc:derby:data/derby_data/alfrescocreate=true
...
...
#db.driver=org.gjt.mm.mysql.Driver
#db.url=jdbc:mysql://localhost/alfresco

becomes

#db.driver=org.apache.derby.jdbc.EmbeddedDriver
#db.url=jdbc:derby:data/derby_data/alfrescocreate=true
...
...
db.driver=org.gjt.mm.mysql.Driver
db.url=jdbc:mysql://localhost/alfresco

In custom-hibernate-dialog.properties, comment out the line for Derby and uncomment the line for MySQL

The Glassfish specific deployment descriptor

Now for the fun bit. Go to the directory in which you unpacked the Alfresco bundle, create a directory called WEB-INF and in that create a file called sun-web.xml with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
 <class-loader delegate="false"/>
 <property name="useMyFaces" value="true"/>
</sun-web-app> 

and then add that file to the alfresco.war file:

$ jar uvf alfresco.war WEB-INF/sun-web.xml
adding: WEB-INF/sun-web.xml(in = 316) (out= 236)(deflated 25%)

You're now ready to start Glassfish and deploy alfresco.war to the Glassfish domain:

$ pfexec /usr/bin/asadmin start-domain domain1
$ /usr/sbin/asadmin deploy alfresco.war
Please enter the admin user name>admin
Please enter the admin password> 
Command deploy executed successfully

Now you should be able to fire up a browser and connect to Alfresco at http://localhost:8080/afresco

Summary

This really just covers the basics and uses a clean OpenSolaris install just to show what actually needs to be done to get it working. Hopefully it can be extrapolated from to help install Alfresco on Glassfish in more complicated scenarios. I'll post this on the Alfresco forums once I'm happy that nothing silly creeped in. Hopefully we can extend this to cover different setups and configurations.

At some point it would be nice to show how to get the PDF to Flash functionality working as currently that's missing,

Troubleshooting

Check that it's using the MySQL database that you created by connecting to MySQL through the mysql command and looking to see if the Alfresco database has a bunch of tables. Also check that /var/alfresco/alf_data contains directories if it doesn't then it probably hasn't picked up the configuration in /var/appserver/domains/domain1/lib/classes/alfresco/extensions. Check that you've used the correct path and that the changes that you made to custom-repository.properties and custom-hibernate-dialog.properties are correct.

Remember to stop and start MySQL (if you need to) using svcadm.

The sun-web.xml file has along line in it, if you cut and paste make sure that it doesn't get split across multiple lines.

If you see any issues or mistakes then post a comment on this blog.

Posted at 06:23PM Oct 10, 2008 by MandyWaite in Open Source  |  Comments[26]

Lighttpd in OpenSolaris

Lighttpd went into the SFW consolidation 6 weeks ago and made it into build 97 of Solaris Nevada (which sees the light of day as Solaris Express Community Edition). It appeared in the OpenSolaris package repository in the first week of September and you can install Lighttpd using the following command:

pfexec pkg install SUNWlighttpd14

if it doesn't find it try running: pfexec pkg refresh and then try it again.

BTW: You don't need to use the pfexec part of the commands if you are logged in as root

I've not blogged about this before because I tried to be clever with dependencies and built the Lighttpd MySQL vhost module against the MySQL 5.0 version that's intergrated into SFW but I deliberately didn't call out the dependency in the packages. This should have meant that when you installed Lighttpd, it wouldn't pull down MySQL, but once you had installed the MySQL packages (if you chose to) then MySQL vhost support would just work. The missing library dependency was spotted by the Gatekeeper and he added the MySQL dependency to the packages by hand. So now when you install Lighttpd, you get MySQL too. Sorry about that.

We have a CR open for this and in the next couple of weeks we'll integrate a fix that packages MySQL support separately. If in the meantime I come up with a way of bypassing the dependency check I'll blog it.

In the meantime, give it a try and if you find anything that doesn't work the way it should or if there's some change you'd like to suggest, reply to this blog entry or join the webstack-discuss alias at http://opensolaris.org/os/discussions/ and send us an email. 

BTW: We don't have lua support at the moment so the likes of mod_magnet won't work, we are hoping to fix this in the near future

Posted at 01:20PM Oct 03, 2008 by MandyWaite in Open Source  |  Comments[0]

Segmentation Fault when running Rails with MySQL on Solaris Nevada

We found in recent testing while integrating Ruby 1.8.6 Patch Level 287 into Solaris Nevada that it's possible to create a situation where Ruby on Rails applications will sometimes crash with a Segmentation Fault. We found that the MySQL native gem when installed, had been built with the mysql.h C header file from MySQL 5.0 but had been linked with an older version of the MySQL client library. This comes about if you install the gem as follows:

gem install mysql -- --with-mysql-dir=/usr/mysql/5.0

In this case the compiler is able to find the C headers in /usr/mysql/5.0/include but because the client library is actually located in /usr/mysql/5.0/lib/mysql/lib, the linker isn't able to find it. As we include /usr/sfw/lib in the build and runtime linker paths for native Ruby Gems, it is able to find the MySQL 4.0 client library and at runtime it links with that. Not surprisingly the MySQL 5.0 C header won't work with the MySQL 4.0 client library, what is surprising is that it works at all and doesn't crash as soon as you try to access MySQL from Ruby.

The solution is to install the gem without specifying any flags, in which case it will compile and link with the MySQL4.0  client, or preferably to specify the path to the include and lib directories of MySQL 5.0. So use either of the following:

gem install mysql -- --with-mysql-lib=/usr/mysql/5.0/lib/mysql -- with-mysql-include=/usr/mysql/5.0/include

gem install mysql

This is not a problem on OpenSolaris as the MySQL 4.0 client library is not there by default, just remember that just using --with-mysql-dir= may not always be enough information for the compiler and linker to do the right thing.

Posted at 12:55PM Oct 03, 2008 by MandyWaite in Open Source  |  Comments[0]

Doing Alfresco stuff in NetBeans

We recently completed a project to detail the steps required to use NetBeans 6.x to build Alfresco and to run the Alfresco SDK. The results of this work can be found at the following links:

Creating an Alfresco Build Environment in NetBeans

Running the Alfresco SDK in NetBeans

Give them a try and feel free to add any feedback to this blog entry.

Thanks to Prem Kumar for doing all of the hard work on these docs.

Posted at 08:00PM May 26, 2008 by MandyWaite in Open Source  |  Comments[20]

NetBeans and jMaki on Mac OS X

I'm a newbie to Mac OS X, I come from a world where I always have the latest jdk installed (OpenSolaris, SXDE), or if I don't (Solaris 10) I just add it using what amounts to muscle memory. Then I move to Mac OS X and twice now I've tried to run Java code that uses JSR-223 (Scripting) and both times it's not worked. It's only because it's ingrained that it should just work that I was able to do ithe same thing twice in two days. So today I installed the Developer Preview 9 of Java SE 6 for Mac OS X. It works so far but why can't it just install in /usr/java? Where it is installed it doesn't even have a bin directory, instead it has "Commands", how posh.

Anyway, I aliased the java and javac commands to point to their 1.6 counterparts and so far it works fine.  Later I tried to run NetBeans with jMaki. After installing the plugin I created a new Web App with jMaki support and it hung at 75%. Being a firm believer that doing the same thing over and over and expecting a different result (the idiot approach) is the safest bet these days, I did it twice and got the same result. Then I noticed that it threw an UnsupportedClassVersionError which is never a good sign. So I modified the netbeans.conf to use the Java SE 1.6 DP and it worked fine.

This is the problem with using 3 OSes. I use various versions of Solaris to do all of my serious work, Windows at home so that I can play games and Mac OS X on my laptop. I gave up doing any kind of programming on Windows ages ago, mainly because i-t-s-n-o-t-u-n-i-x. At least Mac OS X feels like Unix so maybe there's hope. Apple, don't be afraid to provide symlinks in /usr to stuff and 'bin' is a perfectly adequate name for a directory that stores executables.

BTW:  I know that Mac OS X is based on BSD which is goodness, I just don't think that it's mum would recognise it
 

 

 

Posted at 12:56AM Apr 27, 2008 by MandyWaite in Open Source  |  Comments[0]