Comments : 1 Comment »
Categories : Uncategorized
I am no fan of JSF, but watching the eXo portal 2.0 is an eye opener.
This is an open source portal system (GPL) that uses JSF and Pico IoC for its core. It has JSR-168 and JSR-170 support at its core. It uses widgets and Ajax heavilly, and having built the platform they appear to be adding functionality quickly. They have an ECM component (Enterprise Content Management), Workflow (BPEL and XPDL), Groups, Users some Groupware (Calendar, messages) and in the incubator something called exo-lcms with a wiki component and scorm support.
The portlets appear to be velocity (VTL) or JSF based, but when you get to the Skins part of the video…… I think they might be infringing copyright somewhere.
Technical docs are at
1.5M lines, $13M investment, 1.2 years 58 very active developers…. a powerhouse!
Comments : Comments Off on Why Class Extension Pattern with Inner Classes is Bad
Categories : Thought
I’m not against class extension patterns, most of Java is based on it and makes sense, but when you have a class extension model, coupled with inner classes and interfaces, the programmer can express all sorts of bad behavior.
Take the instance where there is a class,A that extends a class,B that extends a class,C. Class C is the generic impl, Class B is the specific and Class A is the heavily bound to say a DB.
Once class B contains inner classes and interfaces, instanced in B and bound to in A, you cant easily extend the classes and inner interfaces in B.
And if the behavior in A (the last in the extension model) overrides the behavior in B, and B adds functionality, you have to constantly search A to check that you don’t need to override as well.
Finally, inner classes tempt you into binding to properties of the parent, binding the inner instance forever inside the parent class.
Small inner classes are probably Ok, but big ones with a tangled web of connections are a pain to work with.
IMHO (having just pulled one of these webs apart to make it compatible with IOC)
Comments : Comments Off on Jackrabbit in a cluster, some pitfalls
Categories : Uncategorized
Although jackrabbit in a cluster does work there are one of 2 issues with the 1.3 code base. There is a small patch that needs to be applied to the CusterNode implementation to make terminate the journal record.
@@ -637,6 +637,7 @@
record = journal.getProducer(PRODUCER_ID).append();
succeeded = true;
After that there is a race condition under load that is a larger patch described in https://issues.apache.org/jira/browse/JCR-929 which will cause the effective node to hang on requests into the JCR. There are also some other things to note, in MySQL clustered environment, you MUST have InnoDB as the default table type otherwise you will get collisions on the revision number. In addition you must have the transaction issolation set to READ-COMMITTED, and not REPEATABLE-READ otherwise you will not see the changes propagate from one of the nodes to the other.