Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

Package org.jbpm.util.experimental.container.lifecycle

This container specification is a runtime environment for loosely coupled components.

See:
          Description

Interface Summary
Startable  
Stopable  
 

Package org.jbpm.util.experimental.container.lifecycle Description

This container specification is a runtime environment for loosely coupled components. 
In my humble opinion, this is what a j2ee-container should have been :-)
My attention slipped for a moment and before I knew, I had written down my
ideas in this orphan package.  Let me know if you should like it.  If I have time 
later this week, I'll finish it :-)

Intro
=====
It is intended as a lightweight easy-to-use
service container that combines the ideas of J2EE and OSGI.
It supports
 * service object pooling
 * aspect oriented programming
 * hot deployment
 * configuration
 
Service archive
===============
To get services deployed in the container you need to create a
service archive (analogue to a .ear or .war archive).  A service
archive can be deployed into the Container by the Deployer.
One service archive can publish any number of services and aspects
into the container (it's not a one-on-one relation).

This is the .jar archive format that is envisioned : 

root
 |  [the root-folder is the publicly visible classpath.  Because 
 |  all other files in a service archive are optional, also a 
 |  standard .jar library a valid service archive]
 +-configuration.xml
 |   [contains all configurations : service layout, service
 |   configurations, aspect configurations]
 +-private
     [is the root of the private implementation classpath.
     these classes are not visible to classes of other 
     service archives.
     'private' is the default implementation classpath,
     another one can be configured in the MANIFEST.MF]

The intention is that a container implementation simply can 
unpack a service archive into a folder.  The configurations 
can then be updated by e.g. the person in the deployer-role
(as in the j2ee-roles) The container implementation can provide
a nice GUI-tool for this configuration task. The configuration.xml
must contain sufficient information for the container to restore
its state after a reboot.

Classloading
============

                   +-------------+
                   |  Container  |
                   | ClassLoader |
                   +-------------+
                         |
       +-----------------+-----------------+
       |                 |                 |
+-------------+   +-------------+   +-------------+
| ClassLoader |   | ClassLoader |   | ClassLoader |
| for service |   | for service |   | for service |
| archive X   |   | archive Y   |   | archive Z   |
+-------------+   +-------------+   +-------------+

The container ClassLoader will 'see' all the classes in the 
public folder of the service archives.  The classloader for 
service archive X will see all the classes if the Container
ClassLoader plus the private classes of service archive X.

configuration.xml
=================
example:
---------------------------------------------------------
<service-archive>
  <service name="Richard" state="available">
    <interface>here.comes.the.FullyQualifiedClassName</interface>
    <interface>here.comes.the.FullyQualifiedClassName2</interface>
    <interface>here.comes.the.FullyQualifiedClassName3</interface>
    <implementation>here.comes.the.FullyQualifiedClassName</implementation>
    <aspect>
      <implementation>here.comes.the.FullyQualifiedClassName</implementation>
      <configuration>
        ...here comes the configuration for the aspect in this aspect-chain...
      </configuration>
    </aspect>
    <aspect>...</aspect>
    <aspect>...</aspect>
    <mapping container-level-name="John" service-level-name="Mike" />
    <mapping container-level-name="John" service-level-name="Mike" />
    <mapping container-level-name="John" service-level-name="Mike" />
    <configuration>
      ...here comes the configuration for the 'Richard'-service...
    </configuration>
  </service>
</service-archive>
---------------------------------------------------------

dtd-fragment: 
---------------------------------------------------------
<!ELEMENT service-archive (service*,aspect*)>
<!ELEMENT service (interface*,implementation,aspect*,mapping*,configuration?)>
<!ATTLIST service name CDATA #IMPLIED
                  state CDATA #IMPLIED>
<!ELEMENT interface #PCDATA>
<!ELEMENT implementation #PCDATA>
<!ELEMENT aspect (implementation,configuration?)>
<!ELEMENT configuration #PCDATA>
---------------------------------------------------------