Java Shopping Cart Hosting
The need to host a shopping cart comes up on a regular basis. There are literally hundreds of very good solutions out there. Here is a list of carts that satisfy the following criteria:
– has a flexible API
– compatible with IBM DB2
With these requirements, Java EE is a good technology to settle on, hence the need to find Java Shopping Cart Hosting.
Java Shopping Cart Hosting – Ready to Go Solutions
The following products have been identified as viable solutions for Java Shopping Cart Hosting deployments:
Java Shopping Cart Hosting – Tutorials
There are also a couple good tutorials we found that would walk you through how to create a shopping cart from scratch to embed into an existing application:
Any of the above is supported in our Managed Hosting environment for a successful Java Shopping Cart Hosting deployment.
One of the great features of DB2 is that it can be extended with custom code using SQL, C/C++, Java and COBOL. One of the great new features added to DB2 in 9.7 is the ability to run native Oracle PL/SQL code, that capability opens up a world of possibilities, and at the same time, the need to extend DB2 with functions that might have been available on the Oracle install and now need to be replicated on DB2. In this short article I describe how to extend DB2 9.7 with Java UDFs.
- Check that Java is properly installed and configured on DB2:
db2 get dbm config|grep JDK
The output should show the path to the JDK installation in DB2. If that isn’t the case, you need to consult the DB2 install manual and make sure Java is installed and configured for DB2.
- Make sure that your user has access to java and javac, and that it is the same version or compatible with DB2’s JDK
- Set the database manager parameter
NO, so that the UDF will be reloaded in each call.
Writing the test code
Creating the UDF in DB2
- Use your favorite text editor or IDE and create a file called
udftest-create.sql with the sample code:
CONNECT TO SAMPLE;
CREATE FUNCTION udftest(VARCHAR(255)) RETURNS VARCHAR(255)
EXTERNAL NAME 'UDFTESTJAR:udftest.udftest'
NOT VARIANT NO SQL PARAMETER STYLE java LANGUAGE java
NO EXTERNAL ACTION;
- Run the scritpt in DB2:
db2 -tvf udftest-create.sql
To check that the function works, run the following command on the command line:
db2 "select udftest('test.com') from sysibm.sysdummy1"
You should get a regular SELECT result set with the expected values. If something goes wrong, you can look at the
db2diag.log that will contain any Java stack trace that would be generated.
To create an MD5 password at the prompt, assuming you have tomcat installed in /usr/local/tomcat, type
$ export TOMCAT="/usr/local/tomcat"
$ java -cp "$TOMCAT/server/lib/catalina.jar:/usr/share/java/jmxri.jar:$TOMCAT/bin/commons-logging-api.jar" \
org.apache.catalina.realm.RealmBase -a md5 [secret]
by replacing “[secret]” with the password.
Some systems have a working
digest.sh script that does the same thing.
If running a legacy java app on a newer RH or RHEL system, youget:
Error occurred during initialization of VM
Unable to load native library:
.../libjava.so: symbol __libc_wait, version GLIBC_2.0 not
defined in file libc.so.6 with link time reference
This is a symptom of an older JDKs that is buggy. Jakub Jelinek of RedHat suggests the following:
gcc -O2 -shared -o ~/libcwait.so -fpic -xc - <<EOF
__libc_wait (int *status)
asm volatile ("pushl %%ebxnt"
"movl %2, %%ebxnt"
"movl %1, %%eaxnt"
: "=a" (res)
: "i" (__NR_wait4), "0" (WAIT_ANY), "c" (status), "d" (0),
and using LD_ASSUME_KERNEL=2.4.19 LD_PRELOAD=~/libcwait.so when you need to load the buggy JDK.