geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Geronimo Wiki] Update of "GBeansArticle1" by TobyCabot
Date Fri, 29 Apr 2005 20:14:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by TobyCabot:
http://wiki.apache.org/geronimo/GBeansArticle1

The comment on the change is:
cleaned up corrupt quotation marks, some grammar

------------------------------------------------------------------------------
  
  The applications that run in a J2EE Container are described by Deployment Descriptors and
Java Classes that are packed as a J2EE application archive.  The Geronimo Deployer parses
those archives and constructs GBeans out of them. When the GBeans are started the application
is deployed and available. The GBeans can be serialized and stored and as a result once an
application is converted to GBeans and added to Geronimo it will be available even after the
server is restarted. 
  
- == GBeans from a Conceptual point of View ==
+ == GBeans From a Conceptual Point of View ==
  
  The concepts that provide the base for the GBeans have much longer history in the sense
that the Geronimo Kernel is an inversion of Control, IOC framework where the  IOC is also
known as the dependency injection. 
  The essence of IOC or the dependency injection is to create a loosely coupled architecture
where the dependencies among components are managed by the framework. When a component has
a dependency on other component the IOC framework will find the correct component and make
it available to the first component. The dependency injection name comes from the fact that
the framework automatically injects the dependencies to the component. 
- Most simple form of IOC or the Dependency injection is to by system wide known values. For
an instance let us assume this is Web Service that is to deployed inside Axis, do not worry
about Axis but just assume that the Axis will load the following class and called the doit()
method. 
+ Most simple form of IOC or the Dependency injection is to by system wide known values. For
an instance let us assume this is Web Service that is to deployed inside Axis, do not worry
about Axis but just assume that the Axis will load the following class and call the doit()
method. 
  
  {{{
  public class WS{
  	public WS(MesageContext msgctx){
- 
          }
  
          public void doit(){
@@ -44, +43 @@

  
  }}}
  
- But Axis has something call !MessageContext that has all the configuration information.
In order to give a reference of !MessageContext to the WS class Axis can say “if you have
a Constructor like XX(!MessageContext) or you have a method like setMessageContext(!MessageContext
msgctx) I will inject the !MessageContext to you”
+ But Axis has something called !MessageContext that has all the configuration information.
In order to give a reference of !MessageContext to the WS class Axis can say "if you have
a Constructor like XX(!MessageContext) or you have a method like setMessageContext(!MessageContext
msgctx) I will inject the !MessageContext to you".
  
  
  This is the simplest form of dependency injection the framework look at the class and find
out that the class expected a  !MessageContext to be inject it in. Or in other words the IOC
framework inspect our components for certain patterns in methods, Parameters and the Constructors
that when the pattern is found provides a Service to the Component, in the example we consider
the service is giving a reference to the message Context. 
@@ -60, +59 @@

  For an example let us consider the how a GBean G1 obtains a reference to a Configuration
Store. The G1 is configured specifying the patterns of the reference it is expected. 
  
  {{{
- e.g. bean.setReferencePatterns(“configStore”,*:type=configStore,*”);
+ e.g. bean.setReferencePatterns("configStore,*:type=configStore,*");
  }}}
  
- When a another GBean whose name match the pattern “*:type=configStore,*” is started it
is automatically injected in to the G1. This is more like Aspect Oriented programming, AOP
where the developer says to the framework what is need to be done rather than how to do it.

+ When a another GBean whose name match the pattern "*:type=configStore,*" is started it is
automatically injected in to the G1. This is more like Aspect Oriented programming, AOP where
the developer says to the framework what is need to be done rather than how to do it. 
  
  	But this does not means that the IOC is the only way to create decoupled systems and all
the four ways of doing is useful and used in practice. It is matter of choosing the right
tool for the occasion and there are good examples as well as bad examples for each.
  
@@ -75, +74 @@

  == State of GBeans ==
  
  GBeans have two types of states, attributes and references. The references will be covered
under the third part. The attributes are two types, persistent and non-persistence. The GBeans
can be stored and restored using the built-in support. 
- There are special types of magic attributes defined by the architecture; the values for
the magic attributes loaded depend on the environment the GBean loaded on. For an example
the magic attribute “kernel” refers to the Kernel and when it is specified at the constructor
it is automatically injected to the class by the framework. Similarly the !ClassLoader attributes
inject the current class loader and the !ObjectName attributes inject the current name the
GBean started under. 
+ There are special types of magic attributes defined by the architecture; the values for
the magic attributes loaded depend on the environment the GBean loaded on. For an example
the magic attribute "kernel" refers to the Kernel and when it is specified at the constructor
it is automatically injected to the class by the framework. Similarly the !ClassLoader attributes
inject the current class loader and the !ObjectName attributes inject the current name the
GBean started under. 
- Complete list of all magic attributes can be found in the GBeanMBean class in the kernel.
 The magic attributes can not be persistent as they are bound with the environment it is started.
Note that in our first example of dependency injection where a Web Service is deployed to
Axis, the !MessageContext is a Magic attribute. 
+ Complete list of all magic attributes can be found in the GBeanMBean class in the kernel.
 The magic attributes can not be persistent as they are bound with the environment it is started.
Note that in our first example of dependency injection where a Web Service is deployed to
Axis, the !MessageContext is a magic attribute. 
+ 
- GBean with one attribute val 1 will be look like this.
+ A GBean with one attribute "val" will look like this:
  
  {{{
  public class MyGBean implements GBeanLifecycle {
@@ -99, +99 @@

  }
  }}}
  
- To starting Our GBean can be done with the following code. The GBean implementation is done
on top of JMX and the GBeanMBean accepts GBean info and convert it in to an Mbean.
+ We can start our GBean with the following code. The GBean implementation is done on top
of JMX and the GBeanMBean accepts a GBean info and converts it into an Mbean.
  
  {{{
  GBeanMBean gmb = new GBeanMBean(MyGBean.GBEAN_INFO);
- gmb.setAttribute(“value”,”To be or not to be that is the question”);
+ gmb.setAttribute("value","To be or not to be that is the question");
- ObjectName myGbeanName = ObjectName.newInstance(“Geronimo.my:name=mine”);
+ ObjectName myGbeanName = ObjectName.newInstance("Geronimo.my:name=mine");
  kernel.loadGBean(myGbeanName,gmb);
  kernel.startGBean(myGbeanName);
  //dowork
@@ -119, +119 @@

   1. Single references 
   1. Reference Collections
  
- ===  Single references ===
+ ===  Single References ===
  
  The references are injected to a GBean in one of the two ways; the getter/setter injection
and the constructor injection based on how the dependencies injected in to the java Class
that use to implements the GBean. With the getter and setter injection framework injects the
attributes/ references using the getter and setter methods whereas the constructor injection
injects the parameters as constructor parameters. The second approach is more preferable as
with that the GBeans support so called good citizen pattern making sure that the GBean is
in usable state once it is started. Geronimo supports both methods but moving towards the
complete constructor injection. 
  
@@ -147, +147 @@

  Here the Line (A) said that there is a reference to the GBean1 and line (B) registered the
matching constructor (C). In the Following code the developer specified the reference instance
of GBean1 and start GBeans.
  
  {{{
- ObjectName GBean1= ObjectName.newInstance(“Geronimo.my:name=gb1”);
+ ObjectName GBean1= ObjectName.newInstance("Geronimo.my:name=gb1");
  ... //start the GBean 1
  GBeanMBean gmb = new GBeanMBean(MyGBean.GBEAN_INFO);
- gmb.setReferencePatterns(“GBean1”, GBean1Name);
+ gmb.setReferencePatterns("GBean1", GBean1Name);
  
- ObjectName myGbeanName = ObjectName.newInstance(“Geronimo.my:name=mine”);
+ ObjectName myGbeanName = ObjectName.newInstance("Geronimo.my:name=mine");
  kernel.loadGBean(myGbeanName,gmb);
  kernel.startGBean(myGbeanName);
  //dowork
@@ -165, +165 @@

  Only difference when the Reference collection come in to play is replacing the GBean1 references
in the above example with Collection and when specifying the name of the referenced GBean
it is specified as a pattern with "*" and "?".
  
  {{{
- bean.setReferencePatterns(“Geronimo.my:*”);
+ bean.setReferencePatterns("Geronimo.my:*");
  }}}
  
- The code asks the framework to make available all the GBeans with the Domain name “Geronimo.my:”.
When a GBean that whose matches the patterns is started it is automatically injected to the
referee GBean. 
+ The code asks the framework to make available all the GBeans with the Domain name "Geronimo.my:".
When a GBean that whose matches the patterns is started it is automatically injected to the
referee GBean. 
  
  ==== Logic in GBeans ====
  
@@ -181, +181 @@

  val2.getClass().getName()}); --------- (A)
  }}}
  
- Kernel supports kernel.invoke(“objectName”,“methodName”,...)  using which one can call
any method in any other GBean. But use of this is discouraged and accepted way to do it is
to register reference pattern and obtain the instance of the other GBean injected in and code
simple Java style on the code. 
+ Kernel supports kernel.invoke("objectName","methodName",...)  using which one can call any
method in any other GBean. But use of this is discouraged and accepted way to do it is to
register reference pattern and obtain the instance of the other GBean injected in and code
simple Java style on the code. 
  
  E.g. Say GBean G1 need to call the doit() on GBean G2 the crude way to do it is to  
  
  {{{
- kernel.invoke(“G2Name”,“doit”);
+ kernel.invoke("G2Name","doit");
  }}}
  
  Correct way to do it is write G1 like 
@@ -215, +215 @@

  
  At line (A) defining there is a reference to G2 and at line (B) adding a constructor that
inject the G2 and G1 obtain a reference to the G2. Then   logic is implemented using simple
Java code. 
  GBeans have interfaces that make the GBean implements a given method. By making the GBean
class implements the interface and putting a entry 
- infoFactory.addInterface(“interfaceName”) will automatically add the all the methods in
the interface to the GBean and the getters and setter will be mapped to the attributes. 
+ infoFactory.addInterface("interfaceName") will automatically add the all the methods in
the interface to the GBean and the getters and setter will be mapped to the attributes. 
  
  == Sample Code  ==
  

Mime
View raw message