
Nukes: the Open Source Java CMS
Pages: 1, 2
Nukes' Architecture Unveiled
Use each technology for what it does the best
We chose JMX to manage Nukes components to provide hot deployment and
component decoupling. This means a component can be removed from the system
while it is running with little or no consequence. A webpage is made of several
tiles, and each "tile" is a component/block/module package. We also wanted to
support completely dynamic web sites, so you can add new modules to a running
instance without service disruption. The jboss-system
module
built on top of core JMX brings us more features than plain vanilla JMX, like
service dependencies. Therefore, each component is an MBean service hooked in
JBoss. The original PostNuke components have a lifecycle, but they do not
handle dependencies at all. Nukes does, leveraging a typical J2EE
specification with some JBoss flavor.
In our port we split data and made a clean separation between management model and the business model. Usually business data need to be scalable and highly configurable, so they are often made of entity EJB components. Our infrastructure leverages the local interfaces introduced since EJB 2.0 because we stay in the same VM all the time. We colocate the web server and the component containers in the same space, avoiding excessive serialization. We do not use data patterns such as DAO or DTO, preferring to use JBoss in its default local mode.
Because of the JMX architecture decision, the hardcore management data is exposed as MBeans attributes. We saw how to change the site name and the site slogan, but you can configure Nukes further this way. Each MBean attribute is persisted in the relational database as well, avoiding the loss of configuration when you restart the server.
Nukes Component Development
It is easy to create a Nukes component from scratch. We are going to create a small module.
Module invocation
Since a module is more or less a set of operations, we need a standard way to invoke them. We chose to keep the original way that PostNuke authors decided to specify invocations in URL syntax. It looks deceptively standard. Each action on a module is triggered when you call a URL that looks like this:
http://localhost:8080/index.html?module=module_name&op=operation_name&...
That URL triggers the operation operation_name
on the module
module_name
. The two parameters, module
and
op
, tell Nukes which operation to invoke on what module. The other
parameters can be fetched by the module by introspection when it is invoked.
Since a module is a JMX MBean, each managed operation that follows the right
pattern may be invoked in this manner. This spells out an invocation that the
JMX server can apply on a target MBean. Behind the scenes, we translate a URL
invocation in a JMX invocation in memory. It is fast and follows the same
naming patterns.
public void operation(org.jboss.Nukes.html.Page page)
If you type the URL with the value of the op
parameter as
operation
, Nukes will call that method on your module object.
Module Creation
PostNuke's module model is almost identical to the servlet model. You code
your page behavior in pure Java. We prefer this to the JSP Model 2
architecture. Let's start with the TemplateModule
class
declaration:
// a module extends the class org.jboss.Nukes.module.ModuleSupport
public class TemplateModule extends ModuleSupport
{
// ...
}
In order to have the Nukes support, your module must extend the
ModuleSupport
class. This has multiple effects:
- Your class will become a module per contract
- You will get access to the Nukes core API
- Nukes can interact with your module and use it for HTML generation purpose
The Nukes API
The major object which you will have to deal with is the Page
object. Let's see how to use it:
/**
* This method is called with the following url:
* http://localhost:8080/Nukes/index.html?module=template
*/
public void main(Page page)
{
page.print("<div align=\"center\">");
page.print("Welcome to the template module");
page.print("</div>");
// print a form that ask for a name
page.print("<table align=\"center\">");
// call Nukes main entry point
page.print("<form action=\"index.html\" method=\"GET\">");
// with module = template
page.print("<input type=\"hidden\" name=\"module\"
value=\"template\"/>");
// and op = action
page.print("<input type=\"hidden\" name=\"op\"
value=\"action\"/>");
// name = XXX
page.print("<tr><td>Type your name:
</td><td><input type=\"text\"
name=\"name\" value=\"\"/></td></tr>");
page.print("<tr><td colspan=\"2\"><input
type=\"submit\"/></td></tr>");
page.print("</form>");
page.print("</table>");
page.print("</div>");
}
As you can see the method main
is called with the following
url:
http://localhost:8080/Nukes/index.html?module=template&op=main
The Page
object is provided as a parameter by the core and is
used by this method to render the HTML content. In this Nukes operation, the
HTML rendered form carries an URL that will activate the method
action
of the module Template
.
Let's see the action
method declared by the
Template
module:
/**
* This method is called with the following url:
* http://localhost:8080/Nukes/index.html?module=template&op=action
*/
public void action(Page page)
{
// get the parameter
String name = page.getParameter("name");
// if no name has been provided, just render the main page again
if (name == null || name.length() == 0)
{
main(page);
return;
}
page.print("<div align=\"center\">");
page.print("Welcome to the template module " + name);
if ( getApi().userLoggedIn() )
{
page.print("you are logged in");
}
page.print("</div>");
}
This method uses Page
as a context object because it stores the
HTTP parameters like the HttpRequest
object in the servlet API.
You can use the Page
API as you do in the servlet API. Another
object that is used by this method is the Api
object returned by
the getApi()
method. It provides services a component may need.
In this case it is used to know whether a user is logged in or not and to
display a message.
Module packaging
The final step in our module creation is deployment. We have to tell JBoss
that the class we just wrote is a Nukes module. The
jboss-service.xml
file declares a Nukes module using the class we
just examined.
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean
code="org.jboss.Nukes.core.modules.user.blocks.LoginBlock"
name="Nukes.blocks:name=login">
<depends>Nukes.modules:name=core</depends>
<attribute name="DisplayName">Template module</attribute>
<attribute name="Description">The Template module</attribute>
</mbean>
</server>
Then we package the class in a jar archive and we add a file
jboss-service.xml
in the META-INF
directory of that
archive. Packaging the file is done with the command jar -cvf
Nukes-template.sar *
. The special extension .sar
tells
JBoss that the packaged file is a service archive.
Figure 7 — the module packaged for deployment
Finally we copy that file into the JBoss deploy directory, where it is automatically deployed. The module can be used without restarting Nukes. Deployment is totally dynamic and is done at runtime.
Figure 8 — the template module is deployed
Final words
What did we learn from our experience? Software that exists is a good place to start even if it is in another language and we are Java snobs. The second lesson was that PHP/PostNuke isn't really designed to handle very high loads. We decided to port to J2EE and leverage many of the existing APIs (JMX and EJB) to provide a straight port of PHP technology that became "enterprise level" almost immediately. That was the real lesson for us, a proof that all the work we do on system level Java pays off in spades at the application level.
Today, the product is maturing. We've ported the majority of the original PostNuke modules and enhanced some of them along the way. Nukes is production ready — it's in production. It has powered the JBoss.org web site for three months without major problems. Its advanced architecture makes it very scalable and easy to work with. We welcome you to come and help us with the porting of modules so we can finally have a decent CMS/Portal base in Open Source Java.
Marc Fleury , Ph.D., is CEO of JBossGroup, LLC. and founder of the JBoss open-source project.
Return to ONJava.com

-
Re:
2009-12-06 23:15:43 martin124 [View]
-
Jahia Java Open Source CMS
2009-09-30 16:51:35 cburne [View]
-
Is there going to be a version that works on Resin
2008-08-05 15:19:29 Crowdness [View]
-
No CMS Programming
2007-12-16 06:44:57 theerasers [View]
-
Dot net nuke port to Nukes on Jboss
2007-07-10 21:55:00 neville.bradbury@opensoftaustralia.com.au [View]
-
Liferay Professional/Enterprise Portal
2005-06-26 22:54:35 mrinal_kanti [View]
-
Open Source Java CMS
2004-03-30 12:04:44 fj_rodriguez [View]
-
Comments on the comments...
2003-12-22 10:35:26 anonymous2 [View]
-
HTML embedded in the Java code???
2003-12-03 16:44:56 anonymous2 [View]
-
HTML embedded in the Java code???
2003-12-03 16:50:14 anonymous2 [View]
-
Error on Sample code's jboss-service.xml ????
2003-08-21 07:18:00 anonymous2 [View]
-
Error on Sample code's jboss-service.xml ????
2004-01-07 09:34:30 anonymous2 [View]
-
How to get source code of Java Nukes
2003-08-05 20:05:35 anonymous2 [View]
-
all good comments
2003-06-27 10:09:31 anonymous2 [View]
-
need help <newbie>
2003-06-10 21:45:24 anonymous2 [View]
-
need help <newbie>
2003-06-11 00:07:26 anonymous2 [View]
-
Use the Power of Java....
2003-06-09 04:11:01 anonymous2 [View]
-
Use the Power of Java....
2003-06-11 03:03:45 anonymous2 [View]
-
Use the Power of Java....
2004-02-12 01:43:10 dabase [View]
-
JLCP!!!
2003-06-09 03:53:24 anonymous2 [View]
-
JLCP!!!
2003-06-09 07:19:12 anonymous2 [View]
-
Confused
2003-06-06 20:02:40 anonymous2 [View]
-
Confused
2003-06-07 04:53:40 anonymous2 [View]
-
inline html
2003-06-06 11:31:14 anonymous2 [View]
-
Hardware specs?
2003-06-06 05:35:10 anonymous2 [View]
-
Hardware specs?
2003-06-09 03:57:07 anonymous2 [View]
-
buzzz know how..
2003-06-06 05:20:04 anonymous2 [View]
-
buzzz know how..
2003-06-09 08:16:25 anonymous2 [View]
-
what about cofax?
2003-06-05 12:53:49 anonymous2 [View]
-
what about cofax?
2003-06-05 12:54:33 anonymous2 [View]
-
Hot deployment across clusters?
2003-06-05 06:13:05 anonymous2 [View]
-
Hot deployment across clusters?
2003-06-05 08:56:15 anonymous2 [View]
-
Missed one: OpenCMS
2003-06-05 05:52:37 anonymous2 [View]
-
this is "enterprise" design?
2003-06-04 23:49:42 anonymous2 [View]
-
Tip
2003-06-04 23:21:56 tomdavies [View]
-
"there was no open source Java CMS"
2003-06-04 20:37:48 akuckartz [View]
-
Java Open Source CMS
2004-04-01 10:16:22 fj_rodriguez [View]
-
Java Open Source CMS
2008-11-26 09:11:31 melenti [View]
-
"there was no open source Java CMS"
2003-06-09 08:30:14 anonymous2 [View]
-
"there was no open source Java CMS"
2003-06-04 21:59:23 anonymous2 [View]
-
"there was no open source Java CMS"
2003-06-05 16:14:36 anonymous2 [View]
-
"there was no open source Java CMS"
2003-06-09 08:17:58 anonymous2 [View]
-
"there was no open source Java CMS"
2003-08-05 07:29:34 anonymous2 [View]
-
"there was no open source Java CMS"
2003-06-10 03:24:59 anonymous2 [View]
-
"there was no open source Java CMS"
2003-06-12 05:23:08 anonymous2 [View]
-
"there was no open source Java CMS"
2003-06-11 15:14:00 anonymous2 [View]
-
the real question behind the article?!
2003-06-11 15:11:38 anonymous2 [View]
