From do-not-reply at jboss.org Wed May 12 08:07:57 2010 Content-Type: multipart/mixed; boundary="===============8865865984016031678==" MIME-Version: 1.0 From: do-not-reply at jboss.org To: gatein-commits at lists.jboss.org Subject: [gatein-commits] gatein SVN: r3065 - portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced. Date: Wed, 12 May 2010 08:07:57 -0400 Message-ID: <201005121207.o4CC7vmV030620@svn01.web.mwc.hst.phx2.redhat.com> --===============8865865984016031678== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: smumford Date: 2010-05-12 08:07:57 -0400 (Wed, 12 May 2010) New Revision: 3065 Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/modules/Advanced/Foundations.xml Log: JBEPP-276: Minor copy edits Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/modules/Advanced/Foundations.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/Foundations.xml 2010-05-12 07:59:24 UTC (r= ev 3064) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/Foundations.xml 2010-05-12 12:07:57 UTC (r= ev 3065) @@ -5,16 +5,16 @@ ]> Foundations -
- GateIn Kernel +
+ The GateIn Kernel &PRODUCT; is built as a set of services on top of a dependency injectio= n kernel. The kernel provides configuration, lifecycle handling, component = scopes, and some core services. - Service components exist in two scopes. First scope is represented by <= emphasis role=3D"bold">RootContainer - it contains services that= exist independently of any portal, and can be accessed by all portals. + Service components exist in two scopes. The first scope is represented = by the RootContainer. It contains servic= es that exist independently of any portal, and can be accessed by all porta= ls. - Second scope is portal-private in the form of P= ortalContainer. Each portal lives in an instance of PortalContai= ner. This scope contains services that are common for a set of portals, and= services which should not be shared by all portals. + The second scope, the PortalContainer, is portal-private. Each portal exists in an instance of PortalContainer.= This scope contains services that are common for a set of portals, and ser= vices which should not be shared by all portals. @@ -27,21 +27,35 @@ - Whenever a specific service is looked up through PortalContainer, and t= he service is not available, the lookup is delegated further up to RootCont= ainer. We can therefore have default instance of a certain component in Roo= tContainer, and portal specific instances in some or all PortalContainers, = that override the default instance. + Whenever a specific service is looked up through PortalContainer, and t= he service is not available, the lookup is delegated further up to RootCont= ainer. = - Whenever your portal application has to be integrated more closely with= GateIn services, the way to do it is by looking up these services through = PortalContainer. Be careful though - only officially documented services sh= ould be accessed this way, and used according to documentation, as most of = the services are an implementation detail of GateIn, and subject to change = without notice. + Therefore &PRODUCT; can have default instance of a certain component in= RootContainer, and portal specific instances in some or all PortalContaine= rs, that override the default instance. + + Whenever your portal application has to be integrated more closely with= GateIn services, these services can be looked up through PortalContainer. = + + + + Only officially documented services should be accessed this way, and u= sed according to documentation, as most of the services are an implementati= on detail of GateIn, and subject to change without notice. + +
=
Configuring services - GateIn Kernel uses dependency injection to create services based on configuration.xml configuration files. The = location of the configuration files determines if services are placed into = RootContainer scope, or into PortalContainer scope. All configuration.xml f= iles located at conf/configuration.xml i= n the classpath (any directory, or any jar in the classpath) will have thei= r services configured at RootContainer scope. All configuration.xml files l= ocated at conf/portal/configuration.xml = in the classpath will have their services configured at PortalContainer sco= pe. Additionally, portal extensions can = contain configuration in WEB-INF/conf/configuration= .xml, and will also have their services configured at PortalCont= ainer scope. + GateIn Kernel uses dependency injection to create services based on configuration.xml configuration files. The location of th= e configuration files determines if services are placed into RootContainer = scope, or into PortalContainer scope. + + All configuration.xml files located at c= onf/configuration.xml in the classpath (any directory, or any ja= r in the classpath) will have their services configured at RootContainer sc= ope. All configuration.xml files located at conf/portal/configuration.xml in the classpath wil= l have their services configured at PortalContainer scope. + + + Additionally, portal extensions can = contain configuration in WEB-INF/conf/configuration.xml, and will also have their services configured at PortalContainer scope. + - Portal extensions are described later on. + Portal extensions are described later in this document.
@@ -51,10 +65,10 @@
Components - A service component is defined in configuratio= n.xml by using <component> element. + A service component is defined in configuration.xml by using <component> element. - There is only one required information when defining a service - the s= ervice implementation class, specified using <ty= pe> + Only one piece of information is required when defining a service; the= service implementation class. This is specified using <type> Every component has a <key> t= hat identifies it. If not explicitly set, a key defaults to the value of &l= t;type>. If key can be loaded as a class, a Class object is used as a ke= y, otherwise a String is used. @@ -62,101 +76,107 @@ The usual approach is to specify an interface as a key. - - Example of service component configuration: - = - -<?xml version=3D"1.0" encoding=3D"ISO-8859-1"?> -<configuration + + + + + org.exoplatform.services.database.HibernateService + org.exoplatform.services.database.impl.HibernateServiceImpl = ... = - </component> -</configuration> - - + +]]> +
=
External Plugins - GateIn Kernel supports non-component objects that can be configured, i= nstantiated, and injected into registered components, using method calls. T= he mechanism is called 'plugins', and allows portal extensions to add addit= ional configurations to core services. + The GateIn Kernel supports non-component objects that can be configure= d, instantiated, and injected into registered components, using method call= s. This 'plugins' method allows portal extensions to add additional configu= rations to core services. - External plugin is defined by using <extern= al-component-plugins> wrapper element which contains one or m= ore <component-plugin> definitions= . <external-component-plugins> uses <targe= t-component> to specify a target service component that will = receive injected objects. + An external plugin is defined by using the <external-compo= nent-plugins> wrapper element which contains one or more <component-plugin> definitions. - Every <component-plugin> defines an implementation type, and a m= ethod on target component to use for injection (<= ;set-method>). + The <external-component-plugins> element uses= <target-component> to specify a target service co= mponent that will receive injected objects. - A plugin implementation class has to implement org.exoplatform.container.component. ComponentPlugin interface. + Every <component-plugin> defines an implement= ation type, and a method on target component to use for injection (<set-method>). - In the following example PortalContainerDefini= tionPlugin implements ComponentPlugin: + A plugin implementation class has to implement the org.exoplatform.container.component. ComponentPlugin interf= ace. - - PortalContainerDefinitionPlugin - = - -<?xml version=3D"1.0" encoding=3D"UTF-8"?> -<configuration + + In the following example PortalContainerDefinitionPlugin implements ComponentPlugin: + + + + = - <external-component-plugins> - <target-component>org.exoplatform.container.definition.PortalC= ontainerConfig</target-component> - <component-plugin> - <!-- The name of the plugin --> - <name>Add PortalContainer Definitions</name> + + org.exoplatform.container.definition.PortalContain= erConfig + + + Add PortalContainer Definitions = - <!-- The name of the method to call on the PortalContainerConf= ig - in order to register the PortalContainerDefinitions --> - <set-method>registerPlugin</set-method> + + registerPlugin = - <!-- The fully qualified name of the PortalContainerDefinition= Plugin --> - <type>org.exoplatform.container.definition.PortalContainerD= efinitionPlugin</type> + + org.exoplatform.container.definition.PortalContainerDefinit= ionPlugin = ... = - </component-plugin> - </external-component-plugins> -</configuration> - - + + +]]> +
=
Includes, and special URLs - It is possible to break configuration.xml file into many smaller files, that are then included into a 'master'= configuration file. The included files are complete configuration xml docu= ments by themselves - they are not fragments of text. + It is possible to the break configuration.xml fil= e into many smaller files, that are then included into a 'master' configura= tion file. - An example configuration.xml that 'outsources' its content into severa= l files: + The included files must be complete configuration.xml documents in themselves. That is, they can not be fragments of text. - = - -<configuration xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" + + Below is an example configuration.xml that 'outso= urces' its content into several files: + + + + + + + = - <import>war:/conf/sample-ext/jcr/jcr-configuration.xml</import= > - <import>war:/conf/sample-ext/portal/portal-configuration.xml</= import> + war:/conf/sample-ext/jcr/jcr-configuration.xml + war:/conf/sample-ext/portal/portal-configuration.xml = -</configuration> - +]]> + + + - We see a special URL being used to reference another configuration fil= e. URL schema 'war:' means, that the pat= h that follows is resolved relative to current PortalContainer's servlet co= ntext resource path, starting at WEB-INF= as a root. + This line is being used to reference another configuration file. The <= literal>war: URL schema indicates that the path that follows is t= o be resolved relative to the current PortalContainer's servlet context res= ource path, starting with WEB-INF as a r= oot. + + + Current PortalContainer is really a newly created PortalContainer, as= war: URLs only make sense for PortalContainer scoped configuration. --===============8865865984016031678==--