www.lateralnz.org

0.9.4a (codename: "Never release in the middle of the night")

Release notes are here.

0.9.4

Release notes are here.

0.9.3 (codename: "Goodbye to the Boss")

Release notes are here.

0.9.2-beta2 (codename: "When is a cube not a cube?")

You can find the release notes here.

0.9.1 (codename: "Mexican Jumping Bean")

major changes to the handling of beans. Rather than having a single instance of a stateless EJB, we are now using Jakarta's pooling library to create a pool of EJB instances. Which means we are now able to support both stateless and stateful session beans. However this does mean that we can no longer have just a single generated file for our EJBs. We now have a separated out EJBHome which is used to retrieve EJB instances. The build process for EJB projects has also been altered slightly as a consequence (SessionBeanWrapperTask renamed to SessionBeanTask, a new velocity template required, etc):
```
<taskdef name="wickertask" classname="org.lateralnz.wicker.deploy.SessionBeanTask">
<classpath>
....
and:
<wickertask ejbjarXML="${src}/META-INF/ejb-jar.xml"
tempdir="${wicker}/temp"
classesdir="${classes}"
wrapperTemplate="sessionbean.vm"
homeWrapperTemplate="sessionbeanhome.vm"
wrapperTemplateDir="${wicker}/etc" />
....
```
added default system properties to wicker.sh so that a context can be created with 'new InitialContext()' (i.e. no properties in the constructor) and still return a LocalContext. This was (temporarily) in s12-jnp-service.py, but it didn't work 100% correctly. Passing in from the command line as a -D property, fixed the problem.
removed the CryptoUtils class. We're adding a lot of crap to it for the commercial side of our business which either means running 2 versions (OSS and proprietary) or just removing it from the OSS project to make my life easier. I've opted for the latter. No great hardship because we weren't using it in the app server anyway (ha. famous last words).
changed the messaging service so that messages are transmitted based upon a match with an allowed or a disallowed regular expression.
added a new broadcast-based messaging service implementation (really just a slight mod of the multicast version)
BUG FIXES:
1. fixing a regex problem with CDATA sections in the preprocess method of XMLUtils
2. changing the cache notification functionality so that it transmits keys and not entire objects (which was a dumb idea to start with, and I should've known it... JRB)
3. new toString method to classes generated by ResultSetConverter
4. fixed a problem where "Supports" beans were always getting a new transaction. NOTE: as of 21/04/2004, "RequiresNew" is still not working the way it should be. It will reuse an existing transaction/connection rather than creating a new one. We'll aim to fix this as soon as possible.
5. localobjects (a hashmap) in LocalContext, which is used to speed up local object lookups (rather than having to resort to RMI), is now a hashmap of hashmaps and is static. This fixed a bug that occurred if you were using 'new InitialContext()' rather than a cached context. Basically, this resulted in a new LocalContext being created each time, so objects would never be locally cached -- hence no performance gain.

0.9.0 (codename: "Now with added vitamins")

Major service configuration/deployment changes. Removed the XML-based configuration mechanism. Originally I wanted to just make this deprecated, but there were too many other fundamental changes I needed to make in the meantime, so it seemed like as good a time as any to tidy up the codebase and get rid of all the unnecessary junk.

We now have no definition of a 'service container'. The SRVC wasn't really a container at all anyway, it was just a handy naming mechanism. Also got rid of init servlet, the container servlet wrapper and the Server main() class (for standalone). All of this has been replaced by Jython scripting and a Launcher servlet/main class.

The launcher reads in python scripts from the etc directory (NOTE: in alphabetical order) and execs each one in turn. This is single threaded, so if you have a startup class that needs to run for an extended length of time, either make it a Thread, or look at Jython/Python's threading model.

As to the reason for replacing the xmlexec facilities, the main one was that while it worked for most configuration operations, to use it for jakarta common's dbcp (database connection pooling) library it was an absolute nightmare (wouldn't work well without a major rewrite). We obviously needed more flexibility in the startup, and a scripting engine is a logical choice. A future goal will be to make the scripting engine pluggable as well, so you can easily replace Jython with your own favourite.
the 'simple transaction' code has been moved out of wicker and into its own package in an attempt to make it more modular. The transaction manager is now deployed with its own python script. Note this does not mean it can be easily replaced -- there's still work needed to be done. Also note that there is still work required on the simpletrans package to bring it more up to spec. It's still defined as an 'almost-but-not-quite' transaction manager.
added UserTransaction to the ssb session context plus into the JNDI registry (as it's supposed to be) as "java:comp/UserTransaction".
added automatic rollback when an exception occurs in the ejb (part of the j2ee spec). Note, this now means that generating the wrappers for the stateless beans is now -extremely- pedantic. If you declare that an exception is thrown in your remote interface, then it had better be thrown in the ejb as well, or you'll get compilation errors.
changed CachedObject so a chain of objects can be returned. The cache update method now looks for this chain and will do an updateCache for each cachedobject in the chain. We do this in our application when our main UserEJB updates some data that effects a number of different services (pseudocode below):
```
<<<PSEUDO
if updated_value is an instanceof a UserEJB data object then
get the list of service ids that will be interested in this data
create a cached object for the first object in the list
for each subsequent object
create a cached object
set the link in the previous cached object to this object
return the first cached object
>>>
```
All this means is that our UserEJB doesn't need to know about the various services that will be interested in its data change. All it needs to be aware of is the fact that there is a cache region who -is- interested. Since the cache loader knows about the services it makes sense to put the relevant code there.

This may or may not be of use to others, but it is for us.

We are working on the cache and messaging services at the moment (see below), so there may be some changes forthcoming.
new SystemUtils method for get a file list with various different extensions
renamed the "notify" package to "messaging" and created a multicast implementation directory. The messaging package now just contains interfaces and a Message object, and the actual implementation (multicast at the moment) is now bound into the registry just like everything else.

I looked into maybe providing JMS or something like MPI, but there seems to be an extreme amount of bloat in most of the specs I looked at -- where we only want lightweight libraries/frameworks. In the meantime we'll carry on with our own and either wrap JMS around it later (if needed) or replace with something else.
more alterations to the build scripts to make it easier for us to build locally (from our subversion repository), and still build the main distribution.
jetty_start.sh replaced with wicker.sh and can now be used to start/stop jetty, and start wicker in standalone mode.
BUG FIXES:
1. added xercesImpl.jar and xmlParserAPIs.jar to the ext/ directory -- these jars are required in order to run wicker standalone. (note: you can quite safely remove them if running in jetty since they're already in jetty's ext directory)
2. wicker.war has been renamed to a_wlauncher.war. The "a_" (hopefully) ensures that it loads first in an environment where webapps are automatically deployed.

0.8.2 (codename: "I wish I'd thought of that")

changed the way services are bound into the system. We had copied the jboss method of using jmx (management extensions/mbeans), but this is complete overkill for such a small system. Instead we've followed Jetty's lead, with a relatively simple XML invocation structure, comprising:


<call ...>  a call to a method on an object or on a class
<new ...> creating a new object
<arg ...> an argument to a call or a new
<bind ...> bind an object to the registry

For example, before we would've created the postgres datasource service as:


<server>
<classpath codebase="." archives=""/>
<mbean code="org.lateralnz.wicker.service.TransDataSourceService"
name="user:service=TRANSDS">
<attribute name="datasource">
<configuration name="postgresql">
<className>org.postgresql.jdbc3.Jdbc3PoolingDataSource</className>
<jndiName>java:/PostgresDS</jndiName>
<property name="dataSourceName">postgresql</property>
<property name="serverName">myserver</property>
<property name="databaseName">mydb</property>
<property name="user">myuser</property>
<property name="password">mypass</property>
<property name="maxConnections">10</property>
</configuration>
</attribute>
</mbean>
</server>

Whereas this has been simplified to:


<bind name="java:/PostgresDS" nonserializable="false" contextname="jnp" server="localhost">
<new class="org.lateralnz.wicker.trans.TransDataSource">
<arg>postgresql</arg>
<arg class="javax.sql.DataSource">
<new class="org.postgresql.jdbc3.Jdbc3PoolingDataSource">
<call method="setDataSourceName"><arg>postgresql</arg></call>
<call method="setServerName"><arg>localhost</arg></call>
<call method="setDatabaseName"><arg>blob</arg></call>
<call method="setUser"><arg>blob</arg></call>
<call method="setPassword"><arg>password</arg></call>
</new>
</arg>
</new>
</bind>

Note 1: the changes are reflected in the two example services (example-mail-service.xml and example-postgres-service.xml). You may notice that the postgres example has increased in size -- and might seem more complex -- but it's actually simplified somewhat, as well as adding new functionality (e.g. a mail Store is bound into the registry as well as the mail Session object).

Note 2: if you're testing/developing/deploying with both JBoss and Wicker and you want to be able to use wicker services in JBoss without too much hassle, there is an MBean wrapper class which will call the XML invocation mechanism. You basically embed the XML to be invoked in a CDATA section within a normal JBoss service descriptor, and it should work the same way as in wicker after that. An example can be found in the file: doc/example-mbeanwrapper-service.xml

fixed a couple of minor issues in the Cache framework. During an add if the loader returns null, the Cache would still try to add to the local map. obviously this would result in a NullPointerException.
belated (ahem) addition of some unit test cases for some of the common/utils stuff. This only been started and will be continuing on. The goal is to have completed unit tests for all relevant classes, plus demos and app server tests, by the time we a release candidate for version 1.0.
minor bug fixes in common/util

Known Issues ============

xmlexec isn't currently set up to pass arrays around. This isn't a high priority at the moment, so if someone requires the functionality, let us know.

0.8.1 (codename: "Slide Sideways Into Oblivion")

Changed the web.xml for wicker.war, removing unnecessary directory info (conf/working), plus made the remaining directory relative. The system property "wicker_home" now needs to be passed in when the application is starting up. See change in start.sh/jetty_start.sh.
split org/lateralnz/common into a separate jar file (lateral-common.jar). Note that jetty_start.sh now has a reference to this file (located in the lib directory)
ensured that non-transactional connections (set to "notsupported") are consequently set to autocommit, and that connections running within a transaction having autocommit set to false

changed JNDIUtils to now look for a <contextname>.params resource, specifying the naming params to lookup. You would define your context as follows:

jnp.params=java.naming.factory.initial,java.naming.provider.url,java.naming.factory.url.pkgs,wicker.naming.factory.initial,wicker.naming.contextname
jnp.java.naming.provider.url=jnp://:1099
jnp.java.naming.factory.initial=org.lateralnz.wicker.naming.LocalContextFactory
jnp.java.naming.factory.url.pkgs=org.jboss.naming
jnp.wicker.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
jnp.wicker.naming.contextname=main

replaced ContextWrapper with LocalContext in a new naming package. This now provides the facility for EJBs to be looked up locally. There are 2 effects of the change:
1. performance improves by a factor of (up to) 10
2. it fixes the transaction/thread bug (where one EJB called by another does not inherit the transaction)
Note: the local context is basically a wrapper on top of a real context (such as JBoss's jnp). This means when creating an initial context when you populate your hashmap you need to include "org.lateralnz.wicker.naming.LocalContextFactory" as the java.naming.factory.initial setting, and then add a couple of extra properties:
```
wicker.naming.factory.initial (set to org.jnp.interfaces.NamingContextFactory, or whatever 'real' naming context you're using)
wicker.naming.contextname (a simple -unique- name to refer to the local context)
```

Known Issues
============

changing the trans. attribute on an ejb does not cause a regeneration of the wrapper you need to manually delete for the moment unfortunately.

0.8.1a (codename: "What the hell were you thinking?")

just discovered a bug binding Reference objects into the LocalContext. Because they're being bound into a local map (as well as the registry), if they're looked up in the same VM then (obviously) the reference isn't being properly resolved into the actual object. For the moment, this has been changed so that all Reference objects are only bound into the JNDI registry.
also added some more info on LocalContext below...
left lateral-common.jar off the classpath in start.sh

0.8.0 - 25 November, 2003

First public alpha release. There's still a bit of tidying up that needs to be done, but this is certainly working for our currently development efforts. Stress testing is still to come, but initial tests indicate it should hold up okay.
The notification & caching system seems to work well in a 2-node cluster (we don't have enough available machines to test more at the moment). Next step is to write a guide for using it and configuring your cluster.
There is occasionally a weird startup problem (IOException) that occurs when an ejb-jar.xml file is parsed (at least on Linux with JDK1.4.2), but stopping and restarting fixes that.
Currently there is no clean shutdown mechanism (CTRL+C just kills the VM immediately)
For anyone who is wondering what all the extra files are in common/util, it's just easier to include them than not. At some point we'll refine the distribution process, so that only necessary files are included.
Currently there's no public access to source control. We're not going to use Sourceforge/CVS for our SC as we're already using Subversion. We'll look at setting up access for other contributors as soon as possible.