(The to-do list has moved onto the site itself.)
IMPORTANT: Things To Do During Deployment
- Make sure that roles are assigned or else no security will be applied at all!
- Make sure that WAR security is enabled.
- Make sure that the subsidiary ports of the J2EE server are protected by the
firewall (eg 9191; see j2sdkee1.3/config/ejb.properties)
- Make sure that the JVM is being run properly, eg in j2sdkee1.3/bin/setenv.sh
add -server to the options in the definitions of JAVACMD.
- Make sure all JNDI names (etc) are set up during deployment.
- Allow appropriate File security rights for application clients (in j2sdkee1.3/lib/security/client.policy)
by ensuring at least the following rights:
permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete,execute";
- Make sure that in j2sdkee1.3/config/default.properties the
passivation.threshold.memory is significantly lower than the
heap limit since very large objects are going to be copied around...
How to Run the Command-line App
See the runit script to run a development copy.
What it does inside is something like:
#!/bin/sh
APPCPATH=out_D/PG2KV0Client.jar; export APPCPATH
exec ./doit runclient -client out_D/PG2KV0.7.2.ear -name PG2Kcl "$@"
where out_D/PG2KV0.7.2.ear is the application archive file,
out_D/PG2KV0Client.jar is the deploytool-generated application client runtime JAE,
and PG2Kcl is the display name of the client to run; in this case the main client.
2001/12/31
- I have PG2K running as a stand-alone WAR, though ready to spilt into
a decoupled master (which is also a normal fully-functioning Web-site)
and front-end slaves.
- The catalogue pages are fairly fully implemented, with a reasonable
built-in search and the ability to build thumbnails for
most (ie currently not-too-huge JPG image) exhibits.
- All catalogue pages are strung togther linearly and to related
exhibits' catalogue pages for the benefit of humans and Web spiders.
2001/04/25
To deploy the EAR in WebLogic (6.0) I do the following:
- Have Filter return immutable List rather than Array, to avoid cloning.
Sort will have to be handled specially.
- In exhibit servlet, check (for GET) If-Modified-Since header, and if present
and client copy of object still current, return appropriate status code
rather than body. I think the container should handle this automatically,
but a few lines from me may fill in where it has overlooked...
- Make sure that all the DOCTYPE xml headers are strictly from the 1.2 spec.
- Add a WEB-INF/weblogic.xml runtime deployment descriptor to the WAR.
- Add an isModified() method to the RawExhibitBean that always returns
false so that WebLogic knows that the data is immutable and need never
be saved.
- Adding:
META-INF/weblogic-ejb-jar.xml
META-INF/weblogic-rdbms-cmp-jar-ExhibitAttr.xml
META-INF/weblogic-rdbms-cmp-jar-ExhibitAux.xml
META-INF/weblogic-rdbms-cmp-jar-RawExhibit.xml
META-INF/weblogic-rdbms-cmp-jar-SysProps.xml
for the beans.jar EJB jars.
- Adding JDBC database pool through WebLogic console. The pool is
called ``demoPool'', its URL is ``jdbc:cloudscape:demoPool;create=true'',
the driver classpath is ``COM.cloudscape.core.JDBCDriver'' and
the properties are given as
``[path]/wlserver6.0/samples/eval/cloudscape/data''.
- Adding ``$WL_HOME/samples/eval/cloudscape/lib/cloudscape.jar'' to classpath given in:
setEnv.sh
startManagedWebLogic.sh
startWebLogic.sh
- The WAR can't find classes from the WEB-INF/lib nor the maifest classpath,
so I'm unpacking them straight into WEB-INF/classes, which is a bit ugly.
- I cannot get WL6.0 to parse 5.1 weblogic-ejb-jar.xml files; it complains about
apparently perfectly legal (and essential) XML elements.
2001/04/29
I have PG2K deployed and running in Sun's J2EE 1.3 Beta SDK and JBoss 2.2.1. Hurrah!
2001/04/25
To deploy the EAR in JBoss (2.2.1) I do the following:
- Unpack JBoss 2.2.1 ZIP and write some wrapper scripts
to set classpaths, invoke the main server, etc.
See JBossSetup.sh and runJBoss.sh.
- Created a skeletal jboss.xml to sit beside ejb-jar.xml and
modified build.xml to incorporate it.
- Removed jboss/deploy/tomcat-test.ear and tomcat/webapps/* for safety,
and removed references to these web apps from tomcat/conf/server.xml.
- Hand-crafted jboss.xml and jaws.xml files for the beans.jar and specified special
handling of the entity bean bulk data.
- After noting that the WAR did not seem to have access to the naming
service at all I modified JBossSetup.sh.
One thing this now does is create a JAVA_CMD that starts Java,
choses server mode, and sets up the naming environment
so that all parts including client app and WAR can see it.
JBoss's jboss/bin/run.sh is modified to use JAVA_CMD
(and an -Xmx128m to allow the heap to expand).
- Because JBoss's Hyperion database has a record-size limit of about 32kBytes,
I wrote the ImmutableFragmentedDataHelperIF interface and implemented
the RawExhibitFragmentedDataHelper class, now used by the ExhibitFacadeBean
rather than interacting directly with the underlying RawExhibit data. This
automatically fragments large data objects across many entity beans, creating
and deleting them in one go, and assembling data for read requests from
as many fragments as necessary. This should improve performance on all
J2EE platforms since it means that smallish and fairly uniform-sized fragments
can be easily handled by the container's cacheing mechanism and are relatively
quick to load. This same mechanism may be useful for properties data and
other aux data, so that is why the implementation was separated from the
interface.
- Altered JBoss-2.2.1_Tomcat-3.2.1/jboss/conf/tomcat/instantdb.properties
to try to make the database behave better for large datasets (and
in particular not to have its log get so enormous):
- Changed resultsOnDisk value to 1 (shipped as 0).
- Changed searchDeletes value to 1 (shipped as 0) since writes are
rare and our data is bulky.
- JBoss 2.2.1 was not shutting Hypersonic down properly on exit.
Have applied HypersonicCloseClean.zip patch from Peter Fagerlund
(see misc/patches) to remedy that.
Problems encountered:
- The built-in database seems to get upset handling byte arrays of about 30kBytes or more.
- Because the client app runs fairly raw, it does not have the java:comp/env JNDI environment
set up and beans, etc, are found directly in ejb/XXX, for example. Also, various system
properties need to be set when running the client to give access to JNDI.
- The WAR does not seem to have its JNDI environment set up for it; presumably the same
global properties need to be set, as for the command-line app, but it is more difficult
to think of a non-toxic way of doing this that does not hurt other deploy platforms.
- There seems to be no security when running a client app.
- The services on Web port 8082 look very vulnerable to me, from a security point of view.
- The ParTasks$TaskProc class is reported as not found in the WAR app.
- The built-in database seems unable to handle records begger than about 32kBytes,
and seems to corrupt the database between runs, which is rather ugly.
2001/04/24
To deploy the EAR in Orion (1.4.5) I do the following:
- Unpack Orion 1.4.5 ZIP and copy JDK (1.3.0/j2se) tools.jar
into the top-level Orion directory.
- Take some garbage out of the deployment descriptors (web.xml
and ejb-jar.xml) that the J2EE 1.3 beta SDK puts in there.
- In Orion's config/default-web-site.xml change the port attribute
of the web-site tag to be 8008 so that this can run non-priv.
Alter the site name, and
create a web-app tag with the app (PG2K) bound at ``/master''.
We arrange for the app to start without waiting for the
first access, and we try to prevent it ever timing out so
as to avoid startup latency, such as relaoding memory-based
caches.
(Maybe we could let the web app time out after hours of inactivity,
but its background CPU activity should be slight anyway and I
don't know yet what the units of the time are for max-inactivity-time.)
<web-site host="[ALL]" port="8008" display-name="PG2K Site">
<default-web-app application="default" name="defaultWebApp" />
<web-app
application="PG2K"
load-on-startup="true"
max-inactivity-time="0"
name="webSvr"
root="/master" />
<access-log path="../log/default-web-access.log" />
</web-site>
- Copy the PG2K app into Orion's applications directory, and add
a tag in its config/server.xml file below the global-application tag:
<application name="PG2K" path="../applications/PG2K.ear" />
- To get round a classpath problem, I copied the ParTasks JAR to
Orion's lib directory.
- Start the server with -userThreads to allow thread creation in
the servlet, eg with a command line of:
/usr/j2se/bin/java -server -jar orion.jar -userThreads
- It seems that it may be necessary to include the following
jndi.properties file in the classpath:
#JNDI Properties (Orion)
java.naming.factory.initial=com.evermind.server.ApplicationClientInitialContextFactory
I am putting this in Orion's lib directory.
- All the example and demo code (and classes) is removed for safety.
- Finally gave up because I was unable to do anything with my client application,
and because the Web component could not access the beans.
2001/03/26
Successfully deployed a stateless session bean (ExhibitFacade)
to provide a transaction-safe view across multiple EJB tables.
2001/03/22
Doing first `date release' version;
will also try to freeze this in SNiFF with a suitable tag.
2001/02/21
Made this sync exhibits, albeit slowly and in small numbers, with
filesystem copies using the generic mechanism; config has been able to do this for a little while.
2001/02/20
See architecture diagram in docs/PG2Karch20010219.rtf
See new client-side command-line app development-time runit script.
2001/02/16
By default, no client authentication seems to be done for the
WAR web components even when resources are listed as protected
with a security constraint.
In j2sdkee1.3/config/security.properties I note a line:
enable.clientauth=false
not to mention many other things that look as if the server is
left wide open.