Mail Archive Home | fractal-commits List | March 2006 Index
| <-- Date Index --> | <-- Thread Index --> |
Date: Thursday, March 30, 2006 @ 11:33:08
Author: seintur
Path: /cvsroot/fractal/web
Added: html/tutorials/aokell/examples/ALoggerController.aj
html/tutorials/aokell/examples/BasicLoggerControllerImpl.java
html/tutorials/aokell/examples/Controller.java
html/tutorials/aokell/examples/DreamLogType.java
html/tutorials/aokell/examples/LoggerController.fractal
html/tutorials/aokell/examples/LoggerControllerItf.java
html/tutorials/aokell/examples/LoggerControllerProcessor.java
html/tutorials/aokell/examples/LoggerControllerTemplate.java
html/tutorials/aokell/examples/LoggerControllerType.fractal
html/tutorials/aokell/examples/Primitive.fractal
html/tutorials/aokell/examples/tutorial.zip
html/tutorials/aokell/figures/bootstrapComponent.jpg
html/tutorials/aokell/figures/componentStructure.jpg
html/tutorials/aokell/figures/componentizedMembranes.jpg
html/tutorials/aokell/figures/controlLayers.jpg
html/tutorials/aokell/figures/flatMembrane.jpg
html/tutorials/aokell/figures/markerTypeSystem.jpg
html/tutorials/aokell/figures/packages.jpg
html/tutorials/aokell/figures/twoLevels.jpg
html/tutorials/aokell/overview.html
xml/root/tutorials/aokell/index-holder.xml
Modified: postprocess.sh xml/root/doc/index.xml
xml/root/download/index.xml xml/root/index.xml
Committing AOKell documentation in the CVS repository containing the web site
sources.
---------------------------------------------------------------+
html/tutorials/aokell/examples/ALoggerController.aj | 86
html/tutorials/aokell/examples/BasicLoggerControllerImpl.java | 298 ++
html/tutorials/aokell/examples/Controller.java | 60
html/tutorials/aokell/examples/DreamLogType.java | 39
html/tutorials/aokell/examples/LoggerController.fractal | 34
html/tutorials/aokell/examples/LoggerControllerItf.java | 27
html/tutorials/aokell/examples/LoggerControllerProcessor.java | 53
html/tutorials/aokell/examples/LoggerControllerTemplate.java | 99
html/tutorials/aokell/examples/LoggerControllerType.fractal | 33
html/tutorials/aokell/examples/Primitive.fractal | 68
html/tutorials/aokell/examples/tutorial.zip | <<Binary
file>>
html/tutorials/aokell/figures/bootstrapComponent.jpg | <<Binary
file>>
html/tutorials/aokell/figures/componentStructure.jpg | <<Binary
file>>
html/tutorials/aokell/figures/componentizedMembranes.jpg | <<Binary
file>>
html/tutorials/aokell/figures/controlLayers.jpg | <<Binary
file>>
html/tutorials/aokell/figures/flatMembrane.jpg | <<Binary
file>>
html/tutorials/aokell/figures/markerTypeSystem.jpg | <<Binary
file>>
html/tutorials/aokell/figures/packages.jpg | <<Binary
file>>
html/tutorials/aokell/figures/twoLevels.jpg | <<Binary
file>>
html/tutorials/aokell/overview.html | 1311
++++++++++
postprocess.sh | 4
xml/root/doc/index.xml | 20
xml/root/download/index.xml | 1
xml/root/index.xml | 4
xml/root/tutorials/aokell/index-holder.xml | 17
25 files changed, 2158 insertions(+), 5 deletions(-)
Index: web/html/tutorials/aokell/examples/ALoggerController.aj
diff -u /dev/null web/html/tutorials/aokell/examples/ALoggerController.aj:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/ALoggerController.aj Thu Mar 30
11:33:06 2006
@@ -0,0 +1,86 @@
+/***
+ * AOKell
+ * Copyright (C) 2005 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ */
+
+package org.objectweb.fractal.aokell.glue;
+
+/**
+ * This aspect introduces the features provided by the logger controller.
+ * These features are introduced for all classes that implement the
+ * LoggerType marker interface.
+ *
+ * @author Lionel Seinturier <Lionel.Seinturier@xxxxxxx>
+ */
+
+import aokell.dream.lib.control.logger.LoggerControllerItf;
+import aokell.dream.lib.membrane.marker.LoggerType;
+import aokell.lib.util.MFractalHelper;
+
+import org.objectweb.dream.control.logger.Loggable;
+
+public aspect ALoggerController {
+
+ // -----------------------------------------------------------
+ // Introduction of the LoggerController interface
+ // Delegate calls to an instance
+ // -----------------------------------------------------------
+
+ public void LoggerType.setBaseName(String name) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ _loggerc.setBaseName(name);
+ }
+
+ public String LoggerType.getBaseName() {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ return _loggerc.getBaseName();
+ }
+
+ public int LoggerType.getLoggerLevel(String loggerName) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ return _loggerc.getLoggerLevel(loggerName);
+ }
+
+ public void LoggerType.setLoggerLevel(String loggerName, int level) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ _loggerc.setLoggerLevel(loggerName,level);
+ }
+
+ public String[] LoggerType.getLoggerNames() {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ return _loggerc.getLoggerNames();
+ }
+
+ // -----------------------------------------------------------
+ // Introduction of the LoggerControllerRegister interface
+ // -----------------------------------------------------------
+
+ public void LoggerType.register(String loggerName, Loggable loggable) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ _loggerc.register(loggerName,loggable);
+ }
+
+ public void LoggerType.unregiser(String loggerName, Loggable loggable) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
MFractalHelper.lookupFcController(getFcMembrane(),"logger-controller");
+ _loggerc.unregiser(loggerName,loggable);
+ }
+
+}
Index: web/html/tutorials/aokell/examples/BasicLoggerControllerImpl.java
diff -u /dev/null
web/html/tutorials/aokell/examples/BasicLoggerControllerImpl.java:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/BasicLoggerControllerImpl.java Thu
Mar 30 11:33:06 2006
@@ -0,0 +1,298 @@
+/**
+ * Dream
+ * Copyright (C) 2003-2004 INRIA Rhone-Alpes
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: dream@xxxxxxxxxxxxx
+ *
+ * Initial developer(s): Matthieu Leclercq
+ * Contributor(s): Lionel Seinturier
+ */
+
+package org.objectweb.fractal.aokell.dream.lib.control.logger;
+
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
+
+import org.objectweb.dream.control.logger.Loggable;
+import org.objectweb.dream.control.logger.LoggerControllerRegister;
+import org.objectweb.dream.control.logger.Util;
+import org.objectweb.fractal.api.Component;
+import org.objectweb.fractal.api.Type;
+import org.objectweb.util.monolog.Monolog;
+import org.objectweb.util.monolog.api.BasicLevel;
+import org.objectweb.util.monolog.api.Logger;
+
+import org.objectweb.fractal.aokell.lib.control.CloneCtrlException;
+import org.objectweb.fractal.aokell.lib.control.Controller;
+import org.objectweb.fractal.aokell.lib.membrane.Membrane;
+
+/**
+ * Basic implementation of logger controller. A
<code>"monolog-conf-file"</code>
+ * initialisation parameter can be set to specify the location of the monolog
+ * configuration file.
+ */
+public class BasicLoggerControllerImpl
+ implements LoggerControllerItf, Controller
+{
+
+ String baseName;
+
+ /** Map associating logger name and list of registred loggables */
+ Map registrations;
+ /** Map associating logger name and logger instance */
+ Map loggers;
+ Logger baseLogger;
+
+
+ public BasicLoggerControllerImpl() {
+ initFcController();
+ }
+
+ private void initFcController() {
+
+ String monologConfFile = "etc/monolog.properties";
+ if (Monolog.monologFactory == Monolog.getDefaultMonologFactory())
+ {
+ Monolog.getMonologFactory(monologConfFile);
+ }
+
+ baseName = Util.getNextUnnamedBaseName();
+ registrations = new HashMap();
+ loggers = new HashMap();
+ }
+
+ //
-------------------------------------------------------------------------
+ // Fields and methods added and overriden by the mixin class
+ //
-------------------------------------------------------------------------
+
+ /**
+ * @see LoggerControllerItf#getBaseName()
+ */
+ public String getBaseName()
+ {
+ return baseName;
+ }
+
+ /**
+ * @see LoggerControllerItf#setBaseName(String)
+ */
+ public void setBaseName(String name)
+ {
+ this.baseName = name;
+ baseNameChanged();
+ }
+
+ /**
+ * @see LoggerControllerItf#getLoggerLevel(String)
+ */
+ public int getLoggerLevel(String loggerName)
+ {
+ Logger l = (Logger) loggers.get(loggerName);
+ if (l == null)
+ {
+ if (loggerName == null)
+ {
+ if (baseLogger == null)
+ {
+ baseLogger = Monolog.monologFactory.getLogger(baseName);
+ }
+ l = baseLogger;
+ }
+ else
+ {
+ return INHERIT;
+ }
+ }
+ int i = l.getCurrentIntLevel();
+ if (i == BasicLevel.DEBUG)
+ return DEBUG;
+ if (i == BasicLevel.INFO)
+ return INFO;
+ if (i == BasicLevel.WARN)
+ return WARN;
+ if (i == BasicLevel.ERROR)
+ return ERROR;
+ if (i == BasicLevel.FATAL)
+ return FATAL;
+ if (i == BasicLevel.INHERIT)
+ return INHERIT;
+ throw new IllegalStateException("Unknown logger level : " + i);
+ }
+
+ /**
+ * @see LoggerControllerItf#setLoggerLevel(String, int)
+ */
+ public void setLoggerLevel(String loggerName, int level)
+ {
+ Logger l = (Logger) loggers.get(loggerName);
+ if (l == null)
+ {
+ if (loggerName == null)
+ {
+ if (baseLogger == null)
+ {
+ baseLogger = Monolog.monologFactory.getLogger(baseName);
+ }
+ l = baseLogger;
+ }
+ else
+ {
+ return;
+ }
+ }
+ switch (level)
+ {
+ case DEBUG :
+ l.setLevel(BasicLevel.LEVEL_DEBUG);
+ break;
+ case INFO :
+ l.setLevel(BasicLevel.LEVEL_INFO);
+ break;
+ case WARN :
+ l.setLevel(BasicLevel.LEVEL_WARN);
+ break;
+ case ERROR :
+ l.setLevel(BasicLevel.LEVEL_ERROR);
+ break;
+ case FATAL :
+ l.setLevel(BasicLevel.LEVEL_FATAL);
+ break;
+ case INHERIT :
+ l.setLevel(BasicLevel.LEVEL_INHERIT);
+ break;
+ default :
+ throw new IllegalArgumentException("Unknown level " + level);
+ }
+ }
+
+ /**
+ * @see LoggerControllerItf#getLoggerNames()
+ */
+ public String[] getLoggerNames()
+ {
+ return (String[]) loggers.keySet().toArray(new String[loggers.size()]);
+ }
+
+ /**
+ * @see LoggerControllerRegister#register(String, Loggable)
+ */
+ public void register(String loggerName, Loggable loggable)
+ {
+ Set s = (Set) registrations.get(loggerName);
+ if (s == null)
+ {
+ s = new HashSet();
+ registrations.put(loggerName, s);
+ }
+ s.add(loggable);
+ giveLogger(loggerName, loggable);
+ }
+
+ /**
+ * @see LoggerControllerRegister#unregiser(String, Loggable)
+ */
+ public void unregiser(String loggerName, Loggable loggable)
+ {
+ Set s = (Set) registrations.get(loggerName);
+ if (s == null)
+ {
+ return;
+ }
+ s.remove(loggable);
+ if (s.isEmpty())
+ {
+ // no more registration for this logger, remove reference to it, for
+ // garbage collector
+ registrations.remove(loggerName);
+ loggers.remove(loggerName);
+ }
+ }
+
+ //
---------------------------------------------------------------------------
+ // Utility methods
+ //
---------------------------------------------------------------------------
+
+ void baseNameChanged()
+ {
+ loggers.clear();
+ Iterator iter = registrations.entrySet().iterator();
+ while (iter.hasNext())
+ {
+ Map.Entry entry = (Map.Entry) iter.next();
+ String loggerName = (String) entry.getKey();
+ Set loggables = (Set) entry.getValue();
+ Iterator iter2 = loggables.iterator();
+ while (iter2.hasNext())
+ {
+ Loggable loggable = (Loggable) iter2.next();
+ giveLogger(loggerName, loggable);
+ }
+ }
+ }
+
+ void giveLogger(String loggerName, Loggable loggable)
+ {
+ Logger logger = (Logger) loggers.get(loggerName);
+ if (logger == null)
+ {
+ String name;
+ if (loggerName == null)
+ {
+ name = baseName;
+ }
+ else
+ {
+ name = baseName + "." + loggerName;
+ }
+ logger = Monolog.monologFactory.getLogger(name);
+ loggers.put(loggerName, logger);
+ }
+ loggable.setLogger(loggerName, logger);
+ }
+
+ // --------------------------------------------------------------
+ // Controller interface
+ // --------------------------------------------------------------
+
+ /**
+ * Initialize the controller.
+ *
+ * @param membrane the membrane which contains the controller
+ */
+ public void initFcCtrl( Membrane membrane ) {
+ // Indeed nothing
+ }
+
+ /**
+ * Clone the controller state from the current component to another one.
+ * This method may receive some hints on how to do this, or provide some
+ * hints on how this has been done. For instance, the hints may be a map
+ * that is read and/or written by the controller. The raison d'être of
+ * these hints is that when its state is cloned, a controller may produce
+ * results that are needed by other controllers.
+ *
+ * @param dst the destination component
+ * @param hints hints for performing the operation
+ */
+ public void cloneFcCtrl( Component dst, Object hints )
+ throws CloneCtrlException {
+ // Indeed nothing for the component controller
+ }
+}
Index: web/html/tutorials/aokell/examples/Controller.java
diff -u /dev/null web/html/tutorials/aokell/examples/Controller.java:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/Controller.java Thu Mar 30 11:33:06
2006
@@ -0,0 +1,60 @@
+/***
+ * AOKell
+ * Copyright (C) 2005 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ */
+
+package org.objectweb.fractal.aokell.lib.control;
+
+import org.objectweb.fractal.api.Component;
+
+/**
+ * Interface for defining a controller.
+ *
+ * @author Lionel Seinturier <Lionel.Seinturier@xxxxxxx>
+ */
+public interface Controller {
+
+ /**
+ * Set the reference towards the component controller associated to this
+ * controller.
+ */
+ public void setFcCompCtrl( Component compctrl );
+
+ /**
+ * Initialize the controller.
+ */
+ public void initFcCtrl();
+
+ /**
+ * Clone the controller state from the current component to another one.
+ * This method may receive some hints on how to do this, or provide some
+ * hints on how this has been done. For instance, the hints may be a map
+ * that is read and/or written by the controller. The raison d'etre of
+ * these hints is that when its state is cloned, a controller may produce
+ * results that are needed by other controllers.
+ *
+ * @param dst the destination component
+ * @param hints hints for performing the operation
+ */
+ public void cloneFcCtrl( Component dst, Object hints )
+ throws CloneCtrlException;
+
+}
Index: web/html/tutorials/aokell/examples/DreamLogType.java
diff -u /dev/null web/html/tutorials/aokell/examples/DreamLogType.java:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/DreamLogType.java Thu Mar 30
11:33:06 2006
@@ -0,0 +1,39 @@
+/***
+ * AOKell
+ * Copyright (C) 2005 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ */
+
+package org.objectweb.fractal.aokell.dream.lib.control.logger;
+
+import org.objectweb.fractal.aokell.lib.membrane.BaseType;
+
+/**
+ * Marker type for components with a Logger controller.
+ *
+ * @author Lionel Seinturier <Lionel.Seinturier@xxxxxxx>
+ */
+public interface DreamLogType
+ extends
+ BaseType,
+ LoggerType
+{
+
+}
Index: web/html/tutorials/aokell/examples/LoggerController.fractal
diff -u /dev/null
web/html/tutorials/aokell/examples/LoggerController.fractal:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/LoggerController.fractal Thu Mar 30
11:33:06 2006
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE definition PUBLIC "-//objectweb.org//DTD Fractal ADL 2.0//EN"
"classpath://org/objectweb/fractal/adl/xml/standard.dtd">
+
+<!--
+ * AOKell
+ * Copyright (C) 2005 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ -->
+
+<definition
+
name="org.objectweb.fractal.aokell.dream.lib.control.logger.LoggerController"
+
extends="org.objectweb.fractal.aokell.dream.lib.control.logger.LoggerControllerType"
>
+
+ <content
class="org.objectweb.fractal.aokell.dream.lib.control.logger.BasicLoggerControllerImpl"
/>
+
+ <controller desc="mPrimitive" />
+</definition>
Index: web/html/tutorials/aokell/examples/LoggerControllerItf.java
diff -u /dev/null
web/html/tutorials/aokell/examples/LoggerControllerItf.java:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/LoggerControllerItf.java Thu Mar 30
11:33:06 2006
@@ -0,0 +1,27 @@
+package org.objectweb.fractal.aokell.dream.lib.control.logger;
+
+import org.objectweb.dream.control.logger.LoggerController;
+import org.objectweb.dream.control.logger.LoggerControllerRegister;
+import org.objectweb.fractal.aokell.lib.type.InterfaceTypeImpl;
+import org.objectweb.fractal.api.type.InterfaceType;
+
+/**
+ * Unified interface for LoggerControllerRegister and LoggerController.
+ * Both interfaces are implemented by BasicLoggerControllerImpl.
+ *
+ * @author Lionel Seinturier <Lionel.Seinturier@xxxxxxx>
+ */
+public interface LoggerControllerItf
+ extends
+ LoggerController,
+ LoggerControllerRegister {
+
+ final public static String NAME = "logger-controller";
+
+ final public static InterfaceType TYPE =
+ new InterfaceTypeImpl(
+ NAME,
+ LoggerControllerItf.class.getName(),
+ false, false, false);
+
+}
Index: web/html/tutorials/aokell/examples/LoggerControllerProcessor.java
diff -u /dev/null
web/html/tutorials/aokell/examples/LoggerControllerProcessor.java:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/LoggerControllerProcessor.java Thu
Mar 30 11:33:06 2006
@@ -0,0 +1,53 @@
+/***
+ * AOKell
+ * Copyright (C) 2006 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ */
+
+package org.objectweb.fractal.aokell.glue;
+
+
+import org.objectweb.fractal.aokell.lib.membrane.marker.NameType;
+
+import spoon.processing.AbstractProcessor;
+import spoon.reflect.declaration.CtClass;
+import spoon.template.Substitution;
+import spoon.template.Template;
+
+/**
+ * This processor introduces the features provided by the name controller.
+ * These features are introduced for all classes that implement the NameType
+ * marker interface.
+ *
+ * @author Lionel Seinturier <Lionel.Seinturier@xxxxxxx>
+ */
+public class LoggerControllerProcessor extends AbstractProcessor<CtClass> {
+
+ public boolean isToBeProcessed(CtClass ct) {
+ return SpoonHelper.impls(ct,DreamLogType.class);
+ }
+
+ public void process(CtClass ct) {
+ Template t = new LoggerControllerTemplate();
+ Substitution.insertAll(ct,t);
+ }
+
+}
+
Index: web/html/tutorials/aokell/examples/LoggerControllerTemplate.java
diff -u /dev/null
web/html/tutorials/aokell/examples/LoggerControllerTemplate.java:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/LoggerControllerTemplate.java Thu
Mar 30 11:33:06 2006
@@ -0,0 +1,99 @@
+/***
+ * AOKell
+ * Copyright (C) 2006 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ */
+
+package org.objectweb.fractal.aokell.glue;
+
+import org.objectweb.fractal.aokell.lib.util.FractalHelper;
+import org.objectweb.fractal.api.Component;
+import aokell.dream.lib.control.logger.LoggerControllerItf;
+
+import spoon.template.Local;
+import spoon.template.Template;
+
+/**
+ * This template defines the elements which are introduced in all classes
+ * which are processed by LoggerControllerProcessor.
+ *
+ * @author Lionel Seinturier <Lionel.Seinturier@xxxxxxx>
+ */
+public class LoggerControllerTemplate implements Template,
LoggerControllerItf {
+
+ @Local
+ public LoggerControllerTemplate() {}
+
+ @Local
+ private Component getFcComponent() {
+ return null;
+ }
+
+ // -----------------------------------------------------------
+ // LoggerController interface implementation
+ // -----------------------------------------------------------
+
+ public void setBaseName(String name) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ _loggerc.setBaseName(name);
+ }
+
+ public String getBaseName() {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ return _loggerc.getBaseName();
+ }
+
+ public int getLoggerLevel(String loggerName) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ return _loggerc.getLoggerLevel(loggerName);
+ }
+
+ public void setLoggerLevel(String loggerName, int level) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ _loggerc.setLoggerLevel(loggerName,level);
+ }
+
+ public String[] getLoggerNames() {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ return _loggerc.getLoggerNames();
+ }
+
+ // -----------------------------------------------------------
+ // LoggerControllerRegister interface implementation
+ // -----------------------------------------------------------
+
+ public void register(String loggerName, Loggable loggable) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ _loggerc.register(loggerName,loggable);
+ }
+
+ public void unregiser(String loggerName, Loggable loggable) {
+ LoggerControllerItf _loggerc = (LoggerControllerItf)
+
FractalHelper.getFcInterface(getFcComponent(),"logger-controller");
+ _loggerc.unregiser(loggerName,loggable);
+ }
+
+}
Index: web/html/tutorials/aokell/examples/LoggerControllerType.fractal
diff -u /dev/null
web/html/tutorials/aokell/examples/LoggerControllerType.fractal:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/LoggerControllerType.fractal Thu
Mar 30 11:33:06 2006
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE definition PUBLIC "-//objectweb.org//DTD Fractal ADL 2.0//EN"
"classpath://org/objectweb/fractal/adl/xml/standard.dtd">
+
+<!--
+ * AOKell
+ * Copyright (C) 2005 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ -->
+
+<definition
name="org.objectweb.fractal.aokell.dream.lib.control.logger.LoggerControllerType">
+ <interface
+ name="//logger-controller"
+
signature="org.objectweb.fractal.aokell.dream.lib.control.Logger.LoggerControllerItf"
+ role="server"
+ />
+</definition>
Index: web/html/tutorials/aokell/examples/Primitive.fractal
diff -u /dev/null web/html/tutorials/aokell/examples/Primitive.fractal:1.1
--- /dev/null Thu Mar 30 11:33:08 2006
+++ web/html/tutorials/aokell/examples/Primitive.fractal Thu Mar 30
11:33:06 2006
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE definition PUBLIC "-//objectweb.org//DTD Fractal ADL 2.0//EN"
"classpath://org/objectweb/fractal/adl/xml/standard.dtd">
+
+<!--
+ * AOKell
+ * Copyright (C) 2005 INRIA, France Telecom
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contact: Lionel.Seinturier@xxxxxxx
+ *
+ * Author: Lionel Seinturier
+ -->
+
+<definition
+ name="org.objectweb.fractal.aokell.lib.membrane.primitive.Primitive"
+
extends="org.objectweb.fractal.aokell.lib.control.logger.LoggerControllerType,org.objectweb.fractal.aokell.lib.control.lifecycle.LifeCycleControllerType,org.objectweb.fractal.aokell.lib.control.binding.BindingControllerType,org.objectweb.fractal.aokell.lib.control.component.ComponentControllerType,org.objectweb.fractal.aokell.lib.control.name.NameControllerType,org.objectweb.fractal.aokell.lib.control.superc.SuperControllerType,org.objectweb.fractal.aokell.lib.control.membrane.MembraneControllerType"
>
+
+ <component name="LogC"
+
definition="org.objectweb.fractal.aokell.lib.control.logger.LoggerController"
/>
+
+ <component name="Comp"
+
definition="org.objectweb.fractal.aokell.lib.control.component.NonCompositeComponentController"
/>
+
+ <component name="NC"
+
definition="org.objectweb.fractal.aokell.lib.control.name.NameController" />
+
+ <component name="LC"
+
definition="org.objectweb.fractal.aokell.lib.control.lifecycle.NonCompositeLifeCycleController"
/>
+
+ <component name="BC"
+
definition="org.objectweb.fractal.aokell.lib.control.binding.PrimitiveBindingController"
/>
+
+ <component name="SC"
+
definition="org.objectweb.fractal.aokell.lib.control.superc.SuperController"
/>
+
+ <component name="MC"
+
definition="org.objectweb.fractal.aokell.lib.control.membrane.MembraneController"
/>
+
+ <binding client="this.//component" server="Comp.//component" />
+ <binding client="this.//name-controller"
server="NC.//name-controller" />
+ <binding client="this.//lifecycle-controller"
server="LC.//lifecycle-controller" />
+ <binding client="this.//binding-controller"
server="BC.//binding-controller" />
+ <binding client="this.//super-controller"
server="SC.//super-controller" />
+ <binding client="this.///membrane-controller"
server="MC.///membrane-controller" />
+
+ <binding client="Comp.//binding-controller"
server="BC.//binding-controller" />
+ <binding client="BC.//component" server="Comp.//component" />
+ <binding client="BC.//super-controller"
server="SC.//super-controller" />
+ <binding client="BC.//name-controller" server="NC.//name-controller"
/>
+ <binding client="LC.//binding-controller"
server="BC.//binding-controller" />
+ <binding client="LC.//component" server="Comp.//component" />
+
+ <controller desc="mComposite" />
+
+</definition>
Index: web/html/tutorials/aokell/examples/tutorial.zip
<<Binary file>>
Index: web/html/tutorials/aokell/figures/bootstrapComponent.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/componentStructure.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/componentizedMembranes.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/controlLayers.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/flatMembrane.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/markerTypeSystem.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/packages.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/figures/twoLevels.jpg
<<Binary file>>
Index: web/html/tutorials/aokell/overview.html
diff -u /dev/null web/html/tutorials/aokell/overview.html:1.1
--- /dev/null Thu Mar 30 11:33:09 2006
+++ web/html/tutorials/aokell/overview.html Thu Mar 30 11:33:07 2006
@@ -0,0 +1,1311 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd";>
+<!--NewPage-->
+<HTML>
+<HEAD>
+<!-- Generated by javadoc (build 1.5.0) on Thu Mar 30 11:15:51 CEST 2006 -->
+<TITLE>
+Overview (AOKell 2.0 Documentation)
+</TITLE>
+
+<META NAME="keywords" CONTENT="Overview, AOKell 2.0 Documentation">
+
+<LINK REL ="stylesheet" TYPE="text/css" HREF="stylesheet.css" TITLE="Style">
+
+<SCRIPT type="text/javascript">
+function windowTitle()
+{
+ parent.document.title="Overview (AOKell 2.0 Documentation)";
+}
+</SCRIPT>
+<NOSCRIPT>
+</NOSCRIPT>
+
+</HEAD>
+
+<BODY BGCOLOR="white" onload="windowTitle();">
+
+
+<!-- ========= START OF TOP NAVBAR ======= -->
+<A NAME="navbar_top"><!-- --></A>
+<A HREF="#skip-navbar_top" title="Skip navigation links"></A>
+<A NAME="skip-navbar_top"></A>
+<!-- ========= END OF TOP NAVBAR ========= -->
+
+<CENTER>
+<H1>
+AOKell 2.0 Documentation</H1>
+</CENTER>
+
+<P align="center">
+<A NAME="overview_description"><!-- --></A> AOKell: an Aspect-Oriented
Implementation of the Fractal
+Specifications<p align="center"><a
href="mailto:Lionel.Seinturier@xxxxxxx";>Lionel Seinturier</a>
+-
+<a href="mailto:Nicolas.Pessemier@xxxxxxx";>Nicolas Pessemier</a> -
+<a href="mailto:thierry.coupaye@xxxxxxxxxxxxxxxxx";>Thierry Coupaye</a><br>
+02/08/06</p>
+
+<p>This documentation is based on the version of AOKell which can be found
in
+the <a href="http://forge.objectweb.org/cvs/?group_id=22";>CVS
repository</a>.</p>
+
+<h2>Table of Contents</h2>
+<ol>
+ <li>
+<a href="#introduction">Introduction</a></li>
+ <li><a href="#membraneTypes">Membrane Types</a></li>
+ <li><a href="#structure">Structure of a Component</a></li>
+ <li><a href="#features">Features</a></li>
+ <li>
+<a href="#codeStructure">Code Structure</a></li>
+ <li>
+<a href="#testsAndApplications">Tests and Applications</a></li>
+ <li>
+<a href="#performances">Performances</a></li>
+ <li>
+<a href="#writing">Writing new Control Membranes</a></li>
+ <li>
+<a href="#conclusion">Conclusion</a></li>
+</ol>
+
+<p>AOKell is INRIA & France Telecom's implementation of the
+<a href="http://fractal.objectweb.org/specification/index.html";>Fractal
Specification</a> <a href="#bibFractal">[1]</a>. This
+document describes the design choices made to implement AOKell and the
overall
+organization of the framework. This document is intended for framework
+developers that want to extend AOKell, but it can also be useful for
component
+developers
+who want to
+understand how AOKell works.</p>
+
+<h2><a name="introduction"></a>1 Introduction</h2>
+
+<p>AOKell is a framework for implementing component controllers and
membranes. As with Julia, the main design goal of AOKell is to implement a
framework to program component
+controllers: we want to implement an extensible set of control objects, from
+which the user can freely choose and assemble the controller objects he or
she
+wants, in order to build the membrane of a Fractal component.</p>
+
+<p>Compared to other implementations of the Fractal model, the first
originality
+of AOKell is to provide a component-based approach for implementing
controllers.
+The control membrane of a component is an assembly of control components.
The
+notions of a client interface, a server interface, a binding, a composite
+component are used at the control level much like they are used at the
business
+level. AOKell is then a reflective model in which the notion of a component
is
+used to engineer both the control level and the application level.</p>
+
+<p>The second originality of AOKell is to use notions from the domain of
+aspect-oriented programming for gluing the application and the control
levels.
+Each control component is associated with an aspect which monitors the
execution
+of the application component and which delegates to the control component
the
+realization of control functionalities. This approach fosters modularity by
+decoupling the implementation of the control from the integration of this
+control in applications. Currently, two alternative implementations of the
glue
+layer are available in the AOKell distribution. The first one relies on
+<a href="http://spoon.gforge.inria.fr";>Spoon</a> <a href="#bibSpoon">[3]</a>
which is a fast open-compiler
+for transforming Java code. The second one relies on the
+aspect-oriented programming language <a
href="http://www.eclipse.org/aspectj";>AspectJ</a>
+<a href="#bibSpoon">
+[2]</a>. By default, the Spoon version is used as this is one which provides
the
+best performances, both in term of compilation time and in term of execution
of
+the compiled code.</p>
+
+<h2><a name="membraneTypes"></a>2 Membrane Types</h2>
+
+<p>AOKell is a level 3.3 implementation of the
+<a href="http://fractal.objectweb.org/specification/index.html";>Fractal
Specification</a>
+(see the specifications for the meaning of compliance levels):</p>
+
+<ul>
+ <li>All components implement the
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/Component.html";>
+ Component</a> interface.</li>
+ <li>The basic controllers (<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/AttributeController.html";>AttributeController</a>,
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/BindingController.html";>
+ BindingController</a>,
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/ContentController.html";>
+ ContentController</a>,
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/LifeCycleController.html";>
+ LifeCycleController</a>,
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/NameController.html";>
+ NameController</a> and
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/SuperController.html";>
+ SuperController</a>) are available.</li>
+ <li>Templates are supported (template components implements the
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/factory/Factory.html";>
+ Factory</a> interface).</li>
+ <li>A Bootstrap component implementing the
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/factory/GenericFactory.html";>
+ GenericFactory</a> and the
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/type/TypeFactory.html";>
+ TypeFactory</a> interface is provided.</li>
+</ul>
+
+<p>A Fractal component is associated to a membrane. The membrane provides a
+level of control and supervision on the component. Membranes can be
decomposed
+into smaller units which are called controllers. A controller implements a
+particular functionality such as controlling the component bindings or
managing
+the lifecycle of the component.</p>
+
+<p>Several types of a membrane can be constructed depending on how
controllers
+are grouped together. Following the Julia membrane type system, we support
13
+different types of a membrane. The two most common ones are:</p>
+
+<ul>
+ <li><b>primitive</b>: provides the binding, lifecycle, naming controllers
and the super controllers.</li>
+ <li><b>composite</b>: provides the same controllers as the ones provided
by
+ primitive, plus the content controller.</li>
+</ul>
+
+<p>With AOKell, each type of a membrane is associated to a marker interface.
The
+membrane interfaces are defined in a hierarchy. Figure 1
+sums up the part of the hierarchy which corresponds to the two
aforementioned
+types. The controller interfaces provided by each type are also mentioned.
Notice
+that a root interface, BaseType, is defined. This interface provides the
Component
+controller and is thus implemented by all components.</p>
+
+<p align="center">
+<img src="../figures/markerTypeSystem.jpg" alt="Membrane types" width="561"
height="197" /></p>
+<p align="center"><b>Fig 1: Membrane types.</b></p>
+
+<p>The interfaces FlatType, PrimitiveType and CompositeType are used to
+type components. For example, a primitive component implements the
PrimitiveType interface,
+which itself implements the SuperController interface, and by extension all
the
+interfaces (BindingController,
+LifeCycleController, etc.) implemented by super-interfaces. </p>
+
+<p>The use of the membrane types hierarchy presented in figure 1 is a design
+choice which is specific to the current version of AOKell. This hierarchy
has
+been set up to factorize definitions, and to reuse as much code as possible.
+However, the use of this hierarchy for implementing membranes and
controllers is
+not mandatory. The glue layer uses this type hierarchy but nothing prevent
+the programmer from implementing membranes and controllers without using
it.</p>
+
+<p>The hierarchy presented in figure 1 is completed with marker interfaces
for
+parametric and template components.</p>
+
+
+<h2><a name="structure"></a>3 Structure of a Component</h2>
+
+
+<p>A Fractal component is composed of a <b>content</b> and is associated to
a
+membrane. The content is
+put under the control and the supervision of the membrane. A membrane can be
+decomposed into smaller units which are called controllers.</p>
+
+
+<p>The purpose of this section is to present the structure set up by AOKell
for
+a Fractal component. Two structures exist:. the AO-structure and the
JL-structure.
+AO stands for aspect-oriented and JL for Julia-like. They are presented
+respectively in Sections 3.1 and 3.2.</p>
+
+
+<h3>3.1 AO-Structure</h3>
+
+
+<p>With AOKell, controllers are programmed as aspects (the orange
+circles on Figure 2) which inject code into the content class and control
its
+behavior. The logic of the controller is not implemented directly into the
+aspect but in a delegated instance which is associated to the aspect (the
+"controller implementations" of Figure 2.)</p>
+
+
+<p align="center">
+<img border="0" src="../figures/componentStructure.jpg" width="202"
height="242"></p>
+
+
+<p align="center"><b>Fig 2: Structure of a component.</b></p>
+
+<p>A Fractal component owns Fractal interfaces. A Fractal interface acts as
an
+entry point (server interface) or an exit point (client interface) for the
+component. A Fractal interface is associated to an
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/type/InterfaceType.html";>
+InterfaceType</a> with a name and a Java interface.</p>
+
+<p align="left">The Fractal interfaces of a component (the green circles on
+Figure 2) are instances which implement the
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/Interface.html";>
+Interface</a> interface and the Java interface defined in their
InterfaceType. The type of a Fractal interface is
+only known at
+runtime when
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/factory/GenericFactory.html#newFcInstance(org.objectweb.fractal.api.Type,
java.lang.Object, java.lang.Object)">
+newFcInstance</a> is called to instantiate a component. This approach is
very dynamic and
+allows creating interface and component types on the fly. Conversely, this
late
+binding mechanism decreases type safety and prevents compile-time checks.</p>
+
+<p>To sum up, the structure of a Fractal component with AOKell is composed
of:</p>
+
+<ul>
+ <li>One instance for the content.</li>
+ <li>One instance per Fractal business interface.</li>
+ <li>One instance per controller.</li>
+</ul>
+
+<p>In addition to that, one needs to mention that, when AspectJ is used,
there
+is also one instance per aspect for the whole application.</p>
+
+<p>This structure could be optimized by merging the controllers with the
+content. For that, the aspects implementing controllers could directly
introduce
+the logic of the controllers into the content class, instead of introducing
a
+pattern which delegates this logic to some external instances.</p>
+
+<h4>Evaluation of the AO-Structure</h4>
+
+<p>With this structure, the control features are directly injected into the
+content by the controllers. This structure is a bit different from the one
+defined by other implementations of the Fractal Specifications such as
Julia.</p>
+
+<p>With Julia, the content and the component are by default, two separated
+instances. The content class is then just a java.lang.Object which is not
aware
+of the controllers. Nevertheless, if the content class implements one or
several
+control interfaces, then this implementation is notified of any call issued
on
+the controllers. For example, if the content class implements the
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/BindingController.html";>
+BindingController</a> interface, then whenever two components are bound, the
bindFc method of the content class will be notified. By implementing the
control
+interfaces, the programmer has then the possibility of reacting to control
+events. Notice that this is not a redefinition of the controllers behavior,
as,
+in all cases, the behaviors implemented in the membrane are always
executed.</p>
+
+<p>The structure implemented by AOKell merges the content and
+the component, whereas, with Julia, the content and the component are
+separated.</p>
+
+<p>The advantage of merging the content and the component is that the
control
+interfaces are directly accessible at the content level. For example, with
AOKell,
+the programmer can write the following content class.</p>
+
+<p><code>public class ClientImpl implements PrimitiveType {<br>
+ public ClientImpl() {}<br>
+ public void run() {<br>
+ Service s = (Service) <b>lookupFc("s");</b><br>
+ s.message();<br>
+ }<br>
+}</code></p>
+
+<p>ClientImpl is controlled by a primitive membrane, and the interfaces of
all
+controllers included in this membrane are then visible. The programmer can
thus
+call the lookupFc method which is implemented by the binding controller. The
+programmer does not have to implement the BindingController interface to
+manipulate bindings as this is the case with Julia. Instead, the programmer
must
+tag the content class as a primitive component. This tagging takes the form
of
+the implementation of the marker interface PrimitiveType.</p>
+
+<h3>3.2 JL-Structure</h3>
+
+<p>While the structure of a Fractal component with AOKell relieves the
+programmer from the pain of implementing control interfaces, this structure
can be problematic for reusing applications
+already written with Julia. In order to facilitate this, AOKell also
provides a
+component structure which is more similar to the one of Julia where:</p>
+
+<ul>
+ <li>The content is free of any injection of control interfaces.</li>
+ <li>If the content class implements control interfaces, the content is
notified
+ whenever a call is issued on the controller implementations.</li>
+</ul>
+
+<p>With the JL-structure, the previous class needs to be written as
follows:</p>
+
+<p><code>public class ClientImpl implements BindingController {<br>
+<br>
+ public ClientImpl() {}<br>
+ public void run() {<br>
+ Service s = (Service) <b>lookupFc("s");</b><br>
+ s.message();<br>
+ }<br>
+<br>
+ public String[] listFc() { return new String[]{"s"}; }<br>
+ public void bindFc(String itfName, Object target) {<br>
+ if( itfName.equals("s") ) { s = (Service)
target; }<br>
+ }<br>
+ public Object lookupFc(String itfName) {<br>
+ if( itfName.equals("s") ) { return s; }<br>
+ return null;<br>
+ }<br>
+ public void unbindFc(String itfName) {<br>
+ if( itfName.equals("s") ) { s = null; }<br>
+ }<br>
+ private Service s;<br>
+}</code></p>
+
+<h3>3.3 Conclusion on the Structure of a Component</h3>
+
+<p>Two structures of a Fractal component are available with AOKell: AO and
JL. With
+the AO-structure, the control interfaces are directly injected into the
+content, and the programmer can use them directly. The JL-structure is
similar to the one implemented by Julia, and facilitates the use of
applications
+developed initially with Julia.</p>
+
+
+<h2><a name="features"></a>4 Features</h2>
+
+
+<p>In order to promote flexibility, the AOKell framework has been decomposed
in
+modules called features. The purpose of this decomposition is
+to introduce some degrees of variability in the framework and to let
developers
+change the implementation of these features. So far, four
+features exist:</p>
+
+<ul>
+ <li>fcinterface: is concerned with the way Fractal interfaces are
generated,</li>
+ <li>glue: is concerned with the way the control and the content are glued
+ together,</li>
+ <li>loggable: is concerned with the ability of having a logger attached to
+ Fractal components,</li>
+ <li>membrane: is concerned with the way control membranes are
implemented.</li>
+</ul>
+
+
+<p>Different implementations of these features are provided with AOKell.
While a
+default implementation is provided for each feature, the developer can still
+choose an alternative version or provide her/his own version by configuring
the
+properties defined in the build.properties file and recompiling AOKell.</p>
+
+
+<h3>4.1 Feature fcinterface</h3>
+
+
+<p>Fractal components provide and require interfaces. These interfaces are
+associated with a signature (defined with a Java interface), a cardinality
+(singleton or collection), a contingency (mandatory or optional) and may be
+client (required) or server (provided). With AOKell these Fractal interfaces
are
+Java classes which implement the
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/Interface.html";>
+Interface</a> interface and the Java interface defined in their signature.
</p>
+
+
+<p>The fcinterface feature is concerned with the way these classes are
generated.
+Two versions of the feature exist:</p>
+
+<ul>
+ <li>rt (default): the class is generated at runtime with the <a
href="http://asm.objectweb.org";>ASM</a>
+ bytecode engineering library,</li>
+ <li>ct: the class is pre-compiled with the
+ InterfaceGenerator tool.</li>
+</ul>
+
+
+<p>The default version of this feature is rt. The rt version is more
dynamic:
+Fractal interface signatures can be determined at very lately, at run-time,
just
+before instantiating the component.</p>
+
+
+<p>With the ct version, all Fractal interfaces are defined at compile-time
and
+the developer can not use at run-time an unforeseen interface. This version
is
+then less flexible. However, with this version, ASM is not needed. In many
+cases, this simplifies the merging of AOKell with other existing framework,
+especially those which themselves, perform bytecode engineering or class
loading.
+For example, this version has been used to port
+<a href="http://www-adele.imag.fr/frogi/";>FROGi</a> to AOKell.</p>
+
+
+<h3>4.2 Feature glue</h3>
+
+
+<p>Two dimensions exist when programming Fractal component: the business
part
+which deals with the core functionalities provided by the component, and the
+control part which deals with the way components are managed. </p>
+
+
+<p>The glue feature deals with the way these two parts are glued together.
Two
+versions of this feature exists:</p>
+
+
+<ul>
+ <li>spoon (default): the glue is implemented with Spoon processors,</li>
+ <li>aspectj: the glue is implemented with AspectJ aspects.</li>
+</ul>
+
+
+<h3>4.3 Feature loggable</h3>
+
+
+<p>As with Julia, Fractal components may be associated with a
+<a href="http://monolog.objectweb.org";>Monolog</a> logger. When this feature
is
+enabled, each primitive component is bound to a logger instance and a
+monolog-factory instance. These instances can be retrieved by calling the
+lookupFc method provided by the BindingController interface.</p>
+
+
+<p>The loggable feature is concerned with whether this feature is enabled or
+not. Two versions of the feature exist:</p>
+
+<ul>
+ <li>off (default): the feature is disabled,</li>
+ <li>on: the feature is enabled.</li>
+</ul>
+
+
+<h3><a name="featureMembrane"></a>4.4 Feature membrane</h3>
+
+
+<p>Control membranes defines the way components are managed.</p>
+
+
+<p>The membrane feature is concerned with the way membranes are implemented.
Two
+versions of the feature exist:</p>
+
+<ul>
+ <li>oo (default): controllers are implemented with Java objects and
control
+ membranes are lists of controllers,</li>
+ <li>comp: controllers are implemented with component, called control
+ components, and control membranes are composites which contain control
+ components and which export control interfaces.</li>
+</ul>
+
+
+<p>The following sub-sections provide more details about the
componentization of
+membranes. Notice that, in both cases the implementation code of controllers
is
+similar. The difference lies in the way the membrane is constructed: a
simple
+list of objects in the first case, and a composite component with
+sub-components, interfaces and bindings in the second case.</p>
+
+
+<h4>4.4.1 Componentized Membranes</h4>
+
+
+<p>Each membrane is decomposed into a set of controllers. The purpose of
this
+decomposition is to separate the various functionalities involved
(lifecycle,
+binding, naming, etc.) and to make them more reusable in different types of
a
+membrane. However, dependencies exist between controllers which prevent
their
+reuse. For example, when considering a flat membrane which provides a
component,
+a naming, a binding and a lifecycle controllers, the following dependencies
can
+be found:</p>
+
+
+<ul>
+ <li>the lifecycle controller depends on the binding controller: indeed,
+ mandatory interfaces must be bound before starting a component. Hence,
before
+ performing the start operation, the lifecycle controller must query the
+ binding controller to check if this condition evaluates to true.</li>
+ <li>the lifecycle controller depends on the component controller: for the
same
+ reason as before, the lifecycle controller has to retrieve the list of
+ mandatory interfaces which is a piece of information managed by the
component
+ controller.</li>
+ <li>the binding controller depends on the component controller: the listFc
+ method defined in the binding control interface returns the names of the
+ client interfaces defined by the current component. This piece of
information is
+ stored by the component controller.</li>
+ <li>the component controller depends on the binding controller: indeed,
when
+ returning the list of component interfaces, the getFcInterfaces method
must return
+ the singleton interfaces and the collection interfaces currently bound.
This
+ last piece of information is stored by the binding controller.</li>
+</ul>
+
+
+<p>Several other dependencies can be defined when considering the other
membrane
+types such as primitive and composite. Notice that these dependencies
depends on
+the semantics chosen for each controller. A different control logic may lead
to
+different dependencies.</p>
+
+
+<p>In our opinion, a pure object-oriented approach is not adequate for
capturing
+these dependencies. The best solution that could be designed would be to
declare
+references and to provide methods for setting and unsetting these
references.
+Yet, this solution is not satisfactory as the dependencies are tangled with
the
+rest of the code. A better solution is to adopt a component-oriented
approach
+and to isolate these dependencies into a software architecture. The solution
+implemented in AOKell is then to provide a component-oriented approach for
+implementing membranes:</p>
+
+
+<ul>
+ <li>each control membrane is associated to a composite component which
exports
+ the control interfaces provided by this membrane,</li>
+ <li>each controller is programmed as a component and is inserted into the
+ previously defined composite component,</li>
+ <li>controllers are bound together depending on the relations deduced from
+ their semantics.</li>
+</ul>
+
+
+<p>Figure 3 illustrates this approach.</p>
+
+
+<p align="center">
+<img border="0" src="../figures/componentizedMembranes.jpg" width="554"
height="263" /></p>
+<p align="center"><b>Fig 3: Componentized membranes</b>.</p>
+
+
+<p>When designing control membranes as components, the expected benefits are
the
+same as the ones expected when designing an application with components:
+to foster the reuse of components (controllers) and to facilitate the
evolution
+of the application (the control logic) by defining explicitly existing
relations
+between components.</p>
+
+
+<h4>4.4.2 Fractalization of the Membrane</h4>
+
+
+<p>Once the principle of defining the control membranes with components and
+bindings has been set up, all the notions and tools defined by Fractal can
be
+reused. Among others, the Fractal API and the Fractal ADL are the two best
+candidates. Hence the architectures of the 13 existing membrane types in
AOKell
+have defined with Fractal ADL. Figure 4 illustrates the architecture of the
flat membrane.
+The Fractal ADL definition follows.</p>
+
+
+<p align="center">
+<img border="0" src="../figures/flatMembrane.jpg" width="291" height="130"
/></p>
+<p align="center"><b>Fig 4: Architecture of the flat membrane type.</b></p>
+
+
+<p><code><!-- o.o.f is a shortcut for org.objectweb.fractal --><br>
+<definition name="o.o.f.aokell.lib.membrane.flat.Flat"<br>
+ extends="o.o.f.aokell.lib.control.component.ComponentControllerType,<br>
+
+o.o.f.aokell.lib.control.name.NameControllerType,<br>
+
+o.o.f.aokell.lib.control.lifecycle.LifeCycleControllerType,<br>
+
+o.o.f.aokell.lib.control.binding.BindingControllerType" >
</code></p>
+
+
+<p><code> <component name="Comp"<br>
+ definition="o.o.f.aokell.lib.control.component.ComponentController"
+/><br>
+<br>
+ <component name="NC"<br>
+ definition="o.o.f.aokell.lib.control.name.NameController"
/><br>
+<br>
+ <component name="LC"<br>
+ definition="o.o.f.aokell.lib.control.lifecycle.NonCompositeLifeCycleController"
/><br>
+<br>
+ <component name="BC"<br>
+ definition="o.o.f.aokell.lib.control.binding.FlatBindingController"
+/><br>
+<br>
+ <binding client="this.component"
server="Comp.component" /><br>
+ <binding client="this.name-controller"
server="NC.name-controller" /><br>
+ <binding client="this.lifecycle-controller"
server="LC.lifecycle-controller" /><br>
+ <binding client="this.binding-controller"
server="BC.binding-controller" /><br>
+<br>
+ <binding client="Comp.binding-controller"
server="BC.binding-controller" /><br>
+ <binding client="BC.component"
server="Comp.component" /><br>
+ <binding client="LC.binding-controller"
server="BC.binding-controller" /><br>
+ <binding client="LC.component"
server="Comp.component"
+/><br>
+<br>
+ <controller desc="mComposite" /><br>
+</definition></code></p>
+
+
+<p>The previous ADL piece of code defines 4 components (controllers) and 8
+bindings. 4 of them are export bindings and the next 4 are normal bindings
+between components. In addition, the Flat component is of type mComposite.
mComposite (resp. mPrimitive) is a new controller description which is
+defined by AOKell for designating composite (resp. primitive) components
which
+implement a control function.</p>
+
+
+<p>We won't go into the details of the other 12 membranes. Their definitions
can
+be find in the AOKell source code (see package
+org.objectweb.fractal.aokell.lib.membrane). The philosophy of control
+membranes with AOKell is summarized in Figure 5.</p>
+
+
+<p align="center">
+<img border="0" src="../figures/twoLevels.jpg" /></p>
+<p align="center"><b>Fig 5: Componentized membranes revisited.</b></p>
+
+
+<h4>4.4.3 Membrane Factory</h4>
+
+
+<p>When instantiating a component, the component factory needs to create a
+membrane (composite component), create the content, and then, link the
content
+to the membrane. A factory is provided by AOKell to create membranes. This
+factory is implemented as an interface (membrane-factory) provided by the
bootstrap component.
+The Java definition of this interface follows.</p>
+
+<p align="center">
+<img border="0" src="../figures/bootstrapComponent.jpg" width="261"
height="63" /></p>
+<p align="center"><b>Fig 6: AOKell bootstrap component.</b></p>
+
+
+<p><code>import org.objectweb.fractal.api.Component;<br>
+import org.objectweb.fractal.api.factory.InstantiationException;<br>
+<br>
+public interface MembraneFactory {<br>
+<br>
+ /**<br>
+ * Return the membrane associated with the given controller
description.<br>
+ */<br>
+ public Component newFcMembrane( Object controllerDesc )<br>
+ throws InstantiationException;<br>
+<br>
+}</code></p>
+
+
+<p>The implementation of the membrane factory relies on the generic
component
+factory. Indeed, few differences exist between business component and
control
+components. They both provide and require interfaces, they are bound with
other
+components, and their architecture is defined with Fractal ADL.</p>
+
+
+<p>In order to save execution time, the ADL definition of the membranes is
+compiled into Java code with the static backend provided by Fractal ADL.
Indeed,
+parsing the ADL definition of the membrane for each newly created business
+component is costly whenever numerous business components, and then
+componentized membranes for these components, need to be
+created. By parsing and compiling membrane definitions once, we save a
+significant amount of execution time.</p>
+
+
+<h4><a name="controllingControllers"></a>4.4.4 Controlling the
Controllers</h4>
+
+
+<p>The rationale for defining control membranes and controllers with
components
+and bindings is to provide a powerful mean to engineer the control dimension
of
+the component model. The idea is that different applications will have
different
+needs in terms of control. The functionalities needed to control embedded
+real-time components is certainly not the same as the one required by
components
+for information systems. Yet, few component models tackle the issue of
engineering
+the control dimension. AOKell addresses this issue by providing the same
notions
+(components and bindings) for engineering the control dimension and the
business
+dimension. The glue between these two dimensions is provided by Spoon
processors
+or AspectJ aspects. By
+offering developers powerful means to program control
+membranes, we hope to promote adaptability and to ensure that applications
will
+be better integrated within various different execution contexts.</p>
+
+
+<p>However, as controllers are programmed as components, the issue of the
+control functions applied to controllers can be raised. This leads to a
three-level
+model where M0 is the business level, M1 is the level controlling M0 and
+M2 is the level controlling M1 (see Figure 7).</p>
+
+
+<p align="center">
+<img border="0" src="../figures/controlLayers.jpg" width="193" height="86"
/></p>
+<p align="center"><b>Fig 7: Control layers.</b></p>
+
+
+<p>As the layering of control functions can not be infinite, we have to
provide
+a way to stop the recursion. Basically, two solutions can be designed:</p>
+<ul>
+ <li>either M2 is implemented with M1: in such a case, a control membrane
(at
+ the M1 level) controls other M1 membranes and provides also the control
+ function for itself,</li>
+ <li>or M2 is implemented as an ad-hoc policy in M1 (hence M2 does not
exists
+ per se).</li>
+</ul>
+<p>The second solution has been implemented with AOKell. The rationale for
this
+choice is that, although we need to adapt the control policy to several
+application domains and execution contexts, the control of controllers is an
+application domain per se, and is unlikely to be subject to tremendous
chances
+over time. Hence, although less flexible, the ad-hoc solution chosen for
level
+M2 is also certainly more efficient than a fully open and reflective
solution.</p>
+
+
+<h3>4.5 Conclusion on Features</h3>
+
+
+<p>The feature mechanism provide some degrees of variability and allow the
+developers to customize the behavior of AOKell. The default feature
+configuration is: fcinterface rt, glue aspectj, loggable off, membrane
component. By
+configuring the properties defined in the build.properties file and
recompiling
+AOKell, the developer can choose his/her own version.</p>
+
+
+<h2><a name="codeStructure"></a>5 Code Structure</h2>
+
+<p>The source code of AOKell is organized in four modules:</p>
+<ul>
+ <li><b>aokell-glue</b>: this module contains the glue (Spoon processors or
+ AspectJ aspects) for integrating control membranes with the application
level.</li>
+
+ <li><b>aokell-component</b>: this module contains the Bootstrap
component.</li>
+
+ <li><b>aokell-lib</b>: this module contains controllers and membranes
+ implementations.</li>
+
+ <li><b>aokell-tools</b>: this module contains some utility tools. These
+ are compile-time tools are not needed at run-time.</li>
+</ul>
+
+<p>All the glue code is packaged in aokell-glue.jar. Two verfsions of this
file
+exist depending on whether the glue feature is set to spoon or to aspectj.
The
+file are named respectively aokell-glue-spoon.jar and
aokell-glue-aspectj.jar. The other modules only
+contain classes and interfaces. These modules can not be used independently:
aokell-glue, aokell-component
+and aokell-tools use classes and interfaces defined in aokell-lib. The
components in aokell-component are
+modified by the glue code contained in aokell-glue.</p>
+<p align="center">
+<img src="../figures/packages.jpg" alt="Package dependencies" width="370"
height="183" /></p>
+<p align="center"><b>Fig 8: Package dependencies.</b></p>
+
+<p>AOKell jar size occupation is 100KB (compared to 180KB for Julia
+2.2): 16KB for aokell-glue-spoon.jar, 2KB for aokell-component.jar and 82KB
for aokell-lib.jar.</p>
+
+<h2><a name="testsAndApplications"></a>6 Tests and applications</h2>
+
+<p>This section reports on the tests and the applications which are
available
+with AOKell.</p>
+
+<h3>6.1 Compliance Tests</h3>
+
+<p>Julia is distributed with a set of 142 <a
href="http://www.junit.org";>JUnit</a> compliance tests. On the 142
+tests, 138 run successfully with AOKell. This section comments on the 6
tests where the behavior of AOKell differs from that of Julia.</p>
+
+<p>The test testParametricPrimitiveTemplate in TestComponent reports an
error,
+because the setter method for the attribute X11 is named setWriteOnlyX11. As
+specified in the Fractal Specifications, AOKell expects a setter method
named
+setX11. In our opinion, the problem lies with the test, not with AOKell.</p>
+
+<p>The test testStarted in TestLifeCycleController assumes that a method
call on
+a stopped interface hangs. This is not an issue related with the Fractal
+Specifications but with the semantics chosen by Julia for lifecycle
controllers. AOKell chooses instead to throw an exception. This test is then
not a Fractal
+test, but a Julia specific one.</p>
+
+<p>The test testWouldCreateNonLocalImportBinding in TestContentController
fails.
+It seems that the test tries to bind a mandatory interface to an optional
one.
+This is not permitted with AOKell.</p>
+
+<p>The test testRemoveNotStopped in TestLifeCycleController fails because
AOKell
+does not automatically starts components when they are added in a composite,
+which is what is assume by the test. As far as we understand the Fractal
+Specifications, this is a Julia specific behavior.</p>
+
+<h3>6.2 Sample Applications</h3>
+
+<p>The following applications are known to run with AOKell:</p>
+
+<ul>
+ <li>comanche: a Web server.</li>
+ <li>Fractal RMI: the extension of Fractal for dealing with remote
components.</li>
+ <li><a
href="http://www.lifl.fr/~moroy/fractalexplorer/fractal_explorer.html";>
+ Fractal Explorer</a>: a run-time graphical console for Fractal
applications.</li>
+ <li><a href="http://gotm.objectweb.org/";>GoTM</a>: a framework for
building
+ transaction services.</li>
+ <li><a href="http://www-adele.imag.fr/frogi/";>FROGi</a>: a framework for
+ packaging Fractal components in OSGi bundles.</li>
+ <li>various "Hello world" examples to illustrate the use of
Fractal ADL,
+ templates, collection interfaces, etc.</li>
+</ul>
+
+<p>Some controllers, originally developed with Julia, have also been
+successfully implemented with AOKell:</p>
+
+<ul>
+ <li><a href="http://dream.objectweb.org/";>Dream</a>: a framework for the
+ construction of communication middleware containing a set of dedicated
+ controllers.</li>
+ <li>Fractal pool: a controller for managing caches.</li>
+</ul>
+
+<p>This initial list of applications and controllers running with AOKell is
+permanently under construction and we welcome any proposal for extending
it.</p>
+
+<h2><a name="performances"></a>7 Performances</h2>
+
+<p>In this section, we compare the performances of AOKell with those of
Julia on
+a test suite known as JACBenchmark, and the performance tests of
+Julia.</p>
+
+<p>The purpose of our benchmark is to evaluate the overhead of running a
"Fractalized" application with AOKell. The purpose is not to
evaluate the time
+needed to compile an AOKell application, nor to evaluate the time taken by
+control operations (such as starting or stopping a component). The times we
are
+measuring are the ones experienced by an end user who is running an
"AOKellized"
+application.</p>
+
+<p>JACBenchmark is a benchmark which we have developed for AOP applications.
+The benchmark has been adapted to support Fractal components. The benchmark
+contains a composite and two primitive components: a client and a server.
The
+server component implements an interface with 8 different methods. Each
method
+implements a different signature. The methods are not empty, but do not
perform
+any interesting stuff (empty methods could distort the benchmark). A warm-up
+procedure is executed before taking any measures to avoid side-effects
introduced
+by the JVM.</p>
+
+<p>The client component issues one million calls on each method of the
server
+interface (total: 8 million calls). The procedure is repeated 4 times. The
+result of the benchmark is the mean time of the 4 measures. The measures are
+taken on a 1.5GHz PC running Windows XP Pro and Sun JDK 1.5.0.</p>
+
+<p>Table 1 compares the results of the current version of AOKell (2.0) to
those of Julia
+2.1.1. The performances of
+AOKell with two different configurations, glue feature implemented with
AspectJ
+or Spoon, are measured. The
+performances of two Julia optimization levels, NONE and MERGEALL, are also
+measured. The optimization level of Julia
+known as MERGEALL consists in merging the content, the controller and the
+interceptors. We also measure the cost of the interception performed by
+the frameworks.</p>
+
+<table>
+<tr>
+<td valign="top">
+
+<table border="1">
+<tr><td colspan="2" rowspan="2"><b>Implementation</b></td>
+ <td colspan="2" align="center">
+ <p align="center"><b>Time (in ms)</b></td></tr>
+<tr><td align="center">lifecycle</td><td align="center">no
lifecycle</td></tr>
+<tr><td rowspan="2">AOKell 2.0</td><td>AspectJ</td><td
align="center">443</td>
+ <td align="center">212</td></tr>
+<tr><td>Spoon</td><td align="center"><b>221</b></td><td
align="center">212</td></tr>
+<tr><td rowspan="2">Julia 2.1.1</td><td>NONE</td><td align="center">484</td>
+ <td align="center">234</td></tr>
+<tr><td>MERGEALL</td><td align="center">396</td><td
align="center">234</td></tr>
+</table>
+
+</td>
+
+<td> </td>
+
+<td valign="top">
+
+<table border="1">
+<tr><td rowspan="2"><b>Implementation</b></td>
+ <td colspan="2" align="center">
+ <p align="center"><b>Time (in ms)</b></td></tr>
+<tr><td align="center">interception</td><td align="center">no
interception</td></tr>
+<tr><td>Pure Java 1.5.0</td><td align="center"><b>172</b></td>
+ <td align="center">122</td></tr>
+<tr><td>AspectJ 1.2.1</td><td align="center">206</td>
+ <td align="center"> </td></tr>
+<tr><td>JBoss AOP 1.1.1</td><td align="center">1046</td>
+ <td align="center"> </td></tr>
+</table>
+
+
+</td>
+</tr>
+</table>
+
+
+<p><b>Tab 1: Cost of invoking and executing an operation (x
8,000,000).</b></p>
+
+<p>The left part of Table 1 compares the figures obtained with AOKell with
those
+obtained with Julia. Two series of figures are given: with the lifecycle
+activated or not. Let remind that this controller performs some interception
on
+incoming calls to implement the lifecycle policy.</p>
+
+<p>A difference between AOKell and Julia can be witnessed when the lifecycle
is
+activated. The main reason for this difference lies in the semantics
implemented
+by the lifecycle controller. With AOKell, this controller rejects calls on
+stopped components. With Julia, the lifecycle controller blocks calls on
stopped
+components and counts the number of executing methods (to avoid removing a
+component which is still executing some requests.) This semantics implies
some
+additional treatments, among others the management of shared data which
needs to
+be synchronized. The cost of these treatments leads to the difference
witnessed
+in Table 1.</p>
+
+<p>Another difference which is worth mentioning concerns the figures for
AOKell with Spoon and AOKell with AspectJ. The results show that Spoon
performs better than AspectJ when
+the lifecycle control comes into play. The reason is that Spoon, being
+a general purpose transformation tool, allows optimizing more aggressively
than
+AspectJ, the transformed code. For example, the interception code can be
+inserted directly into the intercepted methods. By contrast, AspectJ inserts
a
+call to the interception code. This indirection leads to a additional method
+call for every component operation invocation, and thus, multiply by 2 the
cost
+of invoking an operation.</p>
+
+<p>Notice that the performance of AOKell are the same whatever the chosen
+values are for the features loggable, membrane and fcinterface. Indeed,
these
+features only impact the execution time of control functions, not the
+execution time of business methods. Hence, it is worth noticing that there
is no
+cost, in terms of business method execution, in using componentized
membranes
+compared to using membranes with plain old Java objects.</p>
+
+<p>As a matter of comparison, the right part Table 1 gives the execution
time of the same
+benchmark in pure Java (no Fractal components), in AspectJ 1.2.1 and in
JBoss
+AOP 1.1.1. For the first case, a proxy instance is inserted in front of the
+server objects to evaluate the interception cost. For the last two cases,
+AspectJ and JBoss AOP, an empty around advice is woven on
+the server object. Compared to the Java version, the AOKellization with
Spoon
+introduces an overhead of 28% (221ms vs. 172ms), which is in our opinion
+bearable given the benefits brought by the component orientation of Fractal
and
+AOKell.</p>
+
+<h2><a name="writing"></a>8 Writing new Control Membranes</h2>
+
+<p>This section provides, step by step, a guide for writing new controllers
and new control
+membranes with AOKell. As explained in section <a
href="#features">Features</a>,
+two styles of control membranes are supported: object-oriented or
componentized.
+The choice of one of these two modes is a compile-time issue which depends
on
+the value of the fcinterface feature.</p>
+
+<p>Section 8.1 details the writing of plain old Java controllers. This guide
is
+illustrated with an example, a Logger controller, taken from the porting of
the
+<a href="http://dream.objectweb.org";>Dream</a> framework to AOKell. Section
8.2
+revisits this example in the context of componentized membranes.</p>
+
+<p>The whole source code of this tutorial, both for Section 8.1 and Section
8.2,
+can be downloaded in a single <a href="../examples/tutorial.zip">zip
file</a>.</p>
+
+<h3>8.1 POJO controllers</h3>
+
+<p>This section presents the writing of a POJO controller with AOKell.</p>
+
+<p>There is
+
+two ways of writing a POJO controller, depending on whether the controller
is weakly
+or tightly coupled with the component. In the former case, the controller is
+registered with the membrane. This process is presented in Section 8.2.1.
When a
+controller needs to be more tightly coupled, some glue code must be
provided. As
+explained in the previous sections, this glue code may perform injections
and
+interceptions. Section 8.2.2 extends the process of Section 8.2.1 with the
+details of programming the glue code for controllers tightly coupled with
the
+components.</p>
+
+<h4>8.2.1 Simple POJO controllers</h4>
+
+<p>The process of writing a POJO controller goes through the following three
+steps:</p>
+
+<ol>
+ <li>Determining the control interface</li>
+ <li>Implementing the controller</li>
+ <li>Registering the controller</li>
+</ol>
+
+<h4>Step 1: Determining the control interface</h4>
+
+<p>The control interface is the externally visible entry point for the
+controller. For the purpose of our example, we define the
+<a href="../examples/LoggerControllerItf.java">LoggerControllerItf</a>
interface
+which is the aggregation of two existing Dream interfaces:
+<a
href="http://dream.objectweb.org/1.0/javadoc/dream-core/org/objectweb/dream/control/logger/LoggerController.html";>
+LoggerController</a> and
+<a
href="http://dream.objectweb.org/1.0/javadoc/dream-core/org/objectweb/dream/control/logger/LoggerControllerRegister.html";>
+LoggerControllerRegister</a>. Of course, it is not mandatory to write a new
+interface, and the programmer can reuse any existing Java interface (e.g.
+java.lang.Runnable), even if its source code is not available (of course,
the
+bytecode must be available).</p>
+
+<h4>Step 2: Implementing the controller</h4>
+
+<p>A controller is a class which implements a given interface, such as the
one
+previously defined, and the <a
href="../examples/Controller.java">Controller</a>
+interface defined by AOKell. This interface defines three methods:</p>
+
+<p><code>interface Controller {<br>
+ public void setFcCompCtrl( Component compctrl );<br>
+ public void initFcCtrl();<br>
+ public void cloneFcCtrl( Component dst, Object hints ) throws
+CloneCtrlException;<br>
+}</code></p>
+
+<p>The programmer implements these methods but never calls them directly.
They
+are called by the AOKell framework. In addition a controller class must
provided
+a no-argument constructor. The definition of the methods from the Controller
+interface follows:</p>
+
+<ul>
+ <li><code>setFcCompCtrl</code>: the given parameter is the reference of the
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/Component.html";>
+ Component</a> interface associated to the current component. By this way,
+ every controller in a membrane knows the Component identity and can
retrieve
+ any other control interface by invoking getFcInterface().</li>
+ <li><code>initFcCtrl</code>: this method is available for initializing the
+ controller. This method is invoked by the framework after
<code>setFcCompCtrl</code>.
+ The reference to the Component interface is then known and some
initialization
+ treatments, depending on this reference, can be performed.</li>
+ <li><code>cloneFcCtrl</code>: this method is invoked by the
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/factory/Factory.html";>
+ Factory</a> controller to clone the controller state. The given parameters
are
+ the reference of the component which is a clone of the current one, and
some
+ controller-dependant hints which carry additional information to perform
this
+ cloning.</li>
+</ul>
+
+<p>To summarize, the AOKell component factory guarantees that, whatever the
+implementation of the controller is, the invocation order for a newly
created
+controller is:</p>
+
+<ol>
+ <li>no-argument constructor</li>
+ <li><code>setFcCompCtrl</code> method</li>
+ <li><code>initFcCtrl</code> method</li>
+</ol>
+
+<p>As a matter of example, the
+<a
href="../examples/BasicLoggerControllerImpl.java">BasicLoggerControllerImpl</a>
+class is the implementation of our chosen Logger controller.</p>
+
+<h4>Step 3: Registering the controller</h4>
+
+<p>The last step consists in adding our Logger controller into an existing
+membrane or to create a new membrane. In both cases the principle is the
same.
+We illustrate the first case.</p>
+
+<p>The o.o.f.aokell.AOKellMembranes class defines the getMembranes() method
+which returns a description of existing membranes. This method is called by
the
+component factory when a membrane must be created for a new component.
Membranes
+are described by an array of MembraneDef instances.</p>
+
+<p>Each MembraneDef instance contains:</p>
+
+<ul>
+ <li>the name of the membrane as a string (e.g. "primitive",
"composite",
+ etc.),</li>
+ <li>an array of ControllerDef instances,</li>
+ <li>the marker type for the membrane (e.g. PrimitiveType, CompositeType,
etc.).</li>
+</ul>
+
+<p>Each ControllerDef instance describes a controller associated to the
membrane
+and contains:</p>
+
+<ul>
+ <li>the Fractal
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/type/InterfaceType.html";>
+InterfaceType</a> of the control interface,</li>
+ <li>the Java class implementing the controller (e.g.
+<a
href="../examples/BasicLoggerControllerImpl.java">BasicLoggerControllerImpl</a>).</li>
+</ul>
+
+<p>As a matter of example, we can add our Logger controller to the primitive
+membrane by appending the following lines at the end of the ControllerDef
array
+associated to the primitive membrane:</p>
+
+<p><code>new </code><code>ControllerDef</code><code>(<br>
+ new InterfaceTypeImpl(<br>
+ "logger-controller",<br>
+ LoggerControllerItf.class.getName(),<br>
+ false, // server interface<br>
+ false, // mandatory<br>
+ false // singleton<br>
+ ),<br>
+ BasicLoggerControllerImpl.class<br>
+); </code></p>
+
+<p>Once this has been done, all created primitive components hold a new
control
+interface named logger-controller which can be retrieve, as any other
control
+interface, by calling getFcInterface() on the
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/Component.html";>Component</a>
reference.</p>
+
+<h4>8.2.2 POJO controllers with glue code</h4>
+
+<p>The previous process illustrates the writing of a POJO controller with is
+registered with a membrane and which can be retrieved via the
+<a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/Component.html";>Component</a>
+controller. This section extends this process for controller which needs to
be
+more tightly coupled with component implementations and which need to
perform
+code injection or interception. In this case, some glue code needs to be
+provided.</p>
+
+<p>The process of writing a POJO controller with glue code goes through the
five following
+steps:</p>
+
+<ol>
+ <li>Determining the control interface</li>
+ <li>Implementing the controller</li>
+ <li>Defining a marker interface</li>
+ <li>Writing the glue</li>
+ <li>Registering the controller</li>
+</ol>
+
+<p>Steps 1, 2 and 5 are identical to the ones presented in Section 8.2.1. In
the
+remainder of this section, we only details steps 3 and 4.</p>
+
+<h4>Step 3: Defining a marker interface</h4>
+
+<p>This step consists in writing a marker type for our new controller. A
+marker type is an interface, such as java.io.Serializable, whose role is
+to tag a class with a particular property. In our case, we want to let know
that
+our component will be put under the control of our Logger controller. As we
will
+see it in the next step, marker types are used by the glue code to introduce
the
+elements needed by each controller.</p>
+
+<p>Marker interfaces must extends the o.o.f.aokell.lib.membrane.BaseType
+interface defined by AOKell. The <a href="../examples/DreamLogType.java">
+DreamLogType</a> interface defines our marker type.</p>
+
+<p>Note that marker types are most of the time grouped together to form
+aggregate marker types for membranes. For example,
o.o.f.aokell.lib.membrane.primitive.PrimitiveType extends the marker types of
+all controllers contained in a primitive membrane. Although this is not
+mandatory, this interface can then be extended to include our new marker
type.</p>
+
+<h4>Step 4: Writing the glue</h4>
+
+<p>The glue code for a given controller selects the classes
+implementing the associated marker type and performs any transformation
needed
+by this controller. These transformations usually take two forms:</p>
+
+<ul>
+ <li>methods and interface injection: a component class is extended with
some
+ methods and implements a new interface. This is usually the control
interface
+ (in our case
+<a href="../examples/LoggerControllerItf.java">LoggerControllerItf</a>) and
its associated methods.</li>
+ <li>methods interception: some before and/or after treatments may be
+ associated to each method of a component. For example, the lifecycle
+ controller blocks method executions on a stopped component.</li>
+</ul>
+
+<p>Of course, the transformations can take any other forms which is required
by
+the controller.</p>
+
+<p>Two versions of the glue feature of AOKell are available: Spoon or
AspectJ.
+When Spoon is used (which is the default case) a processor must be written.
In
+the case of AspectJ, an aspect must be written. As a matter of example, the
+classes <a href="../examples/LoggerControllerProcessor.java">
+LoggerControllerProcessor</a> and
+<a
href="../examples/LoggerControllerTemplate.java">LoggerControllerTemplate</a>
implement the Spoon glue code, and the
+<a href="../examples/ALoggerController.aj">ALoggerController</a> aspect
+implements the AspectJ version.</p>
+
+<p>This document does not go into the details of programming with
+<a href="http://spoon.gforge.inria.fr/";>Spoon</a> or
+<a href="http://www.eclipse.org/aspectj/";>AspectJ</a>. The reader is either
+supposed to be familiar with these tools, or to refer to their respective
web
+sites for documentation.</p>
+
+<h3>8.2 Component controllers</h3>
+
+<p>When componentized membranes are used, e.g. when the membrane feature is
set
+to comp, the process of writing a controller goes through the following six
+steps:</p>
+
+<ol>
+ <li>Determining the control interface</li>
+ <li>Implementing the controller</li>
+ <li>Defining a marker interface</li>
+ <li>Writing the glue</li>
+ <li>Membrane architecture description</li>
+ <li>Registering the membrane</li>
+</ol>
+
+<p>Steps 1 to are identical to the ones presented in the previous section.
As
+with POJO controller, it is not mandatory for component controllers to be
+associated with glue code. Hence, steps 3 and 4 can be skipped. For clarity
sake,
+the following description assumes that this is not the case. </p>
+
+<p>Although step 2, Implementing the controller, does not differ from the
POJO
+version, two points can be mentioned:</p>
+
+<ul>
+ <li>The compctrl reference transmitted to setFcCompCtrl is the reference
of the
+ M2-level component controller (see Section <a
href="#controllingControllers">Controlling the Controllers</a>)
+ and not the reference of the M1-level component controller as this is the
case
+ with POJO controllers.</li>
+ <li>The controller implementation is the content of a so-called control
+ component, which is a regular Fractal component. Hence:<ul>
+ <li>the Fractal API can be used to manipulate these components,</li>
+ <li>these components provide a
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/BindingController.html";>
+ BindingController</a>, a
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/NameController.html";>
+ NameController</a> and a
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/SuperController.html";>
+ SuperController</a> interface,</li>
+ <li>composite control components can be used and, in this case, a
+ <a
href="http://fractal.objectweb.org/current/doc/javadoc/fractal/org/objectweb/fractal/api/control/ContentController.html";>
+ ContentController</a> interface is also available,</li>
+ <li>collection interfaces are supported,</li>
+ <li>note however that:<ul>
+ <li>these control components are unstoppable and do not provide a
+ lifecycle control interface,</li>
+ <li>template control components are not supported.</li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+</ul>
+
+<h4>Step 5: Membrane architecture description</h4>
+
+<p>As described in Section <a href="#featureMembrane">Feature membrane</a>,
the
+componentization of control membranes reify the communication paths and the
+dependencies between controllers. The purpose is to apply to the development
of
+the membrane the concepts which have been applied to the development of
+applications when components were introduced.</p>
+
+<p>A control membrane is then an assembly of control components described
with
+Fractal-ADL. Two new controller descriptions have been introduced: <code>
+mComposite</code> and <code>mPrimitive</code>. They correspond respectively,
to
+a composite control component and to a primitive control component. A
control
+membrane is then a <code>mComposite </code>component containing other <code>
+mComposite</code> or <code>mPrimitive </code>sub-components. The interfaces
+exported by the root <code>mComposite</code> component are the control
+interfaces provided by the application-level component controlled by this
+membrane.</p>
+
+<p>When a new membrane is requested to the membrane factory, the
corresponding
+Fractal-ADL assembly is instantiated. However, this is not the XML
definition of
+the assembly, but its Java description generated by a static Fractal-ADL
Java
+backend which is used. This solution is slightly less flexible (indeed, Java
+descriptions must be regenerated whenever the XML descriptions change), but
is
+more performant (executing a block of Java code is far less costly than
parsing
+and interpreting an XML document.)</p>
+
+<p>In the case of our example, the Logger controller can be inserted in an
+existing membrane or in a new one. We illustrate the first case by extending
the
+primitive membrane with this controller. The
+<a href="../examples/Primitive.fractal">Primitive</a>,
+<a href="../examples/LoggerController.fractal">LoggerController</a> and
+<a href="../examples/LoggerControllerType.fractal">LoggerControllerType</a>
+definitions implement this extension. </p>
+
+<h4>Step 6: Registering the membrane</h4>
+
+<p>As with the POJO version, componentized membranes need to be registered
in
+the AOKellMembrane class. However, the definition of MembraneDef changes for
+componentized membranes. It contains:</p>
+
+<ul>
+ <li>the name of the membrane as a string (e.g. "primitive",
"composite",
+ etc.),</li>
+ <li>the name of the control membrane Fractal-ADL definition as a string
(in
+ our case
"org.objectweb.fractal.aokell.lib.membrane.primitive.Primitive"),</li>
+ <li>the marker type for the membrane (e.g. PrimitiveType, CompositeType,
etc.).</li>
+</ul>
+
+<p>Once this has been done, all created primitive control membranes contain
a
+LogC control component which export a logger-controller interface. This
+interface is available for the application component controlled by this
+membrane.</p>
+
+<h2><a name="conclusion"></a>9 Conclusion</h2>
+
+<p>This document presents AOKell which is INRIA and France Telecom's
+implementation of the Fractal component model. This is a full Java
+implementation (level 3.3) of the Fractal Specifications.</p>
+
+<p>The difference between AOKell and other existing implementations is that
AOKell uses Aspect-Oriented Programming and the AspectJ language for
+implementing controllers and membranes. In our opinion, compared to other
+techniques such as mixins, this leads to a controller development style
which is
+easier to understand, debug and maintain. We have shown in this document
that,
+while providing a high level of abstraction for programming controllers as
+aspects, Fractal applications developed with AOKell do not suffer from
runtime
+penalties: performances of AOKell applications are similar to those
developed
+with Julia.</p>
+
+<p>We believe that this experiment shows that AOP and AspectJ are mature
tools
+for engineering complex applications such as the ones developed with Fractal
+components.</p>
+
+<h2>Acknowledgment</h2>
+
+<p>This work is partially funded by France Telecom under the external
research
+contract #46131097.</p>
+
+<h2>References</h2>
+<p><a name="bibFractal"></a>[1] E. Bruneton, T. Coupaye, M. Leclercq, V.
Quema,
+J.-B. Stefani. <i>An Open Component Model and Its Support in Java</i>. 7th
+International Symposium on Component-Based Software Engineering (<a
href="http://www.sei.cmu.edu/pacc/CBSE7/";>CBSE-7</a>),
+LNCS 3054, pp. 7-22, May 2004, Springer.<br>
+<a name="bibAOP"></a>[2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C.
+Lopes, J.-M. Loingtier, J. Irwin. <i>Aspect-Oriented Programming</i>. 11th
+European Conference on Object-Oriented Programming (ECOOP'97), LNCS 1241,
pp.
+220-242, June 1997, Springer.<br>
+<a name="bibSpoon"></a>[3] R. Pawlak. <i>
+<a
href="http://middleware05.objectweb.org/WSProceedings/AOMD05/a6-pawlak.pdf";>
+Spoon: Annotation-Driven Program Transformation the AOP Case</a></i>. 1st
+International Workshop on Aspect-Oriented Middleware Development (<a
href="http://middleware05.objectweb.org/WSProceedings/AOMD05/index.html";>AOMD'05</a>)
+ @ ACM/IFIP/Usenix <a
href="http://middleware05.objectweb.org";>Middleware'05</a>,
+November 2005.</p>
+
+<h2>Document history</h2>
+<ul>
+ <li>3/8/06 : Section Writing new Control Membranes added</li>
+ <li>2/8/06 : Spoon-related information added (v2.0)<br>
+ </li>
+ <li>1/10/06 : Section Features added</li>
+ <li>12/8/05 : Sections on membrane types and component
+ structure updated</li>
+ <li>4/24/05 : Initial release of this document (v1.0)</li>
+</ul>
+
+<hr>
+
+<p align="left"><i><a href="mailto:Lionel.Seinturier@xxxxxxx";>Lionel
Seinturier</a>,
+<a href="mailto:Nicolas.Pessemier@xxxxxxx";>Nicolas Pessemier</a>,
+<a href="mailto:thierry.coupaye@xxxxxxxxxxxxxxxxx";>Thierry Coupaye</a>.<br>
+</i>Last modified:
+<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%m/%d/%y" startspan
-->03/30/06<!--webbot bot="Timestamp" endspan i-checksum="13002" -->.</p>
+
+</BODY>
+</HTML>
\ No newline at end of file
Index: web/postprocess.sh
diff -u web/postprocess.sh:1.3 web/postprocess.sh:1.4
--- web/postprocess.sh:1.3 Tue Mar 16 12:29:44 2004
+++ web/postprocess.sh Thu Mar 30 11:33:07 2006
@@ -23,3 +23,7 @@
cd ../jmx
sed -e '/TOBEREPLACED/r body.html' -e '/TOBEREPLACED/d' index-holder.html >
index.html
sed -e '/TOBEREPLACED/r body.html' -e '/TOBEREPLACED/d' -e '/- Fractal JMX
tutorial/d' index-holder_print.html > index_print.html
+
+cd ../aokell
+sed -e '/TOBEREPLACED/r overview.html' -e '/TOBEREPLACED/d'
index-holder.html | sed -e 's/..\/figures\//figures\//' | sed -e
's/..\/examples\//examples\//' > index.html
+sed -e '/TOBEREPLACED/r overview.html' -e '/TOBEREPLACED/d' -e '/- AOKell
documentation/d' index-holder_print.html | sed -e
's/..\/figures\//figures\//' > index_print.html
Index: web/xml/root/doc/index.xml
diff -u web/xml/root/doc/index.xml:1.12 web/xml/root/doc/index.xml:1.13
--- web/xml/root/doc/index.xml:1.12 Tue Feb 21 14:06:41 2006
+++ web/xml/root/doc/index.xml Thu Mar 30 11:33:07 2006
@@ -45,12 +45,26 @@
<p>The goal of this sub project is to provide implementations
of the Fractal component model.</p>
- <p>Julia is the reference implementation of the Fractal component
- model in Java. The <a href="../tutorials/julia/index.html">Julia
+ <ul>
+
+ <li><strong>Julia</strong> is the reference implementation of the
+ Fractal component model in Java.
+ The <a href="../tutorials/julia/index.html">Julia
Tutorial</a> explains how Julia can be configured. The
<a href="../current/doc/javadoc/julia/overview-summary.html">Julia
API</a> documentation explains how Julia is designed and
- implemented.</p>
+ implemented.</li>
+
+ <li><strong><a
href="../tutorials/aokell/index.html">AOKell</a></strong>
+ is another full implementation of the specifications in Java.
+ AOKell differs from Julia, in the way control membrane and
+ components are glued together (AOKell uses aspect-oriented
+ programming for that), and in the way control membranes are
+ implemented (AOKell proposes the notion of a control component
+ and of assemblies of control components for implementing membranes).
+ </li>
+
+ </ul>
<!--p>ProActive is another implementation, which is conform to the 3.2
<a
href="../specification/index.html#sub:Conformance-levels">conformance
Index: web/xml/root/download/index.xml
diff -u web/xml/root/download/index.xml:1.6
web/xml/root/download/index.xml:1.7
--- web/xml/root/download/index.xml:1.6 Tue Mar 16 12:29:44 2004
+++ web/xml/root/download/index.xml Thu Mar 30 11:33:07 2006
@@ -43,6 +43,7 @@
<li><em>fractaljmx</em>: used to get the Fractal JMX agent.</li>
<li><em>fractalswing</em>: used to get the Fractal Swing components.</li>
<li><em>julia</em>: used to get the Julia reference implementation.</li>
+ <li><em>aokell</em>: used to get the AOKell implementation.</li>
<li><em>examples</em>: used to get the Fractal examples.</li>
<li><em>web</em>: used to get the Fractal web site.</li>
</ul>
Index: web/xml/root/index.xml
diff -u web/xml/root/index.xml:1.9 web/xml/root/index.xml:1.10
--- web/xml/root/index.xml:1.9 Fri Feb 17 13:28:37 2006
+++ web/xml/root/index.xml Thu Mar 30 11:33:07 2006
@@ -83,10 +83,10 @@
including non ObjectWeb projects:</p>
<ul>
-<li><a href="http://aofractal.gforge.inria.fr/";>AOKell</a>
+<li><a href="tutorials/aokell/index.html">AOKell</a>
is an implementation similar to Julia, but based on AspectJ instead of
mixins.
It can execute the same applications as Julia, including Fractal RMI,
Fractal
-ADL, Fractal Explorer...</li>
+ADL, Fractal Explorer.</li>
<li><a href="http://csl.ensm-douai.fr/FracTalk";>FracTalk</a> is a SmallTalk
implementation of the Fractal component model.</li>
<li><a href="http://www-adele.imag.fr/fractnet/";>FractNet</a> is a .Net
Index: web/xml/root/tutorials/aokell/index-holder.xml
diff -u /dev/null web/xml/root/tutorials/aokell/index-holder.xml:1.1
--- /dev/null Thu Mar 30 11:33:09 2006
+++ web/xml/root/tutorials/aokell/index-holder.xml Thu Mar 30 11:33:07
2006
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
+
+<!DOCTYPE document SYSTEM '../../../../common/dtd/objectweb.dtd'>
+
+<document>
+
+ <properties>
+ <author email="fractal@xxxxxxxxxxxxx">fractal-team</author>
+ <title>AOKell Documentation</title>
+ <filename>index.xml</filename>
+ <pathtoroot>../..</pathtoroot>
+ </properties>
+
+ <body>
+ <s1 name="TOBEREPLACED"/>
+ </body>
+</document>
| <-- Date Index --> | <-- Thread Index --> |
Powered by MHonArc.
Copyright © 2006-2007, OW2 Consortium | contact | webmaster.