xdocs/proposals/application-service.xml - turbine-core - Git at Google

 <?xml version="1.0"?>
 <!--
 /*
  * Copyright 2001-2004 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
  *
  *      http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
  -->

 <document>

   <properties>
     <title>Application Service Proposal</title>
   </properties>

 <body>

 <section name="Description">
   <p>
     The application services would allow fully functional Turbine applications
     to be packaged up in the form of JAR files and deployed during Turbine
     startup.
   </p>
 </section>

 <section name="Rationale">
 <p>
 </p>
 </section>

 <section name="Requirements">
 <ul>
   <li>
     Turbine would probably process a directory of JAR files
     that contain sub-applications. The manifest would contain
     a set of instructions to be used by the application service
     so that the sub-application would be processed correctly
     and usable by Turbine. This may be the module.packages
     to add, or template paths to add, or whatever else is
     needed to bootstrap the sub-application.
   </li>

   <li>
     Module packages have to be dynamically configurable.
     The assembler broker must accept additional packages
     to look in for modules after the system has started.
   </li>

   <li>
     Must be able to load templates from JAR files. Velocity
     can do this, and it can probably be done for the other
     template services as well.
   </li>

   <li>
     Configuration information must be able to enter a
     running Turbine application. A sub application might
     have many forms of configuration info. It might be properties
     that have to be accessible via TurbineResources. Or
     it might configuration information to be used by one
     of the services, say for example an intake XML descriptor
     for the input forms used in the sub-application.
     <p/>
     The services in general might need some work to allow
     dynamic configuration so that sub-applications can
     really work properly.
   </li>

   <li>
     Sub-applications may require certain operations to be
     executed in order to run. This might be a forum application
     that has an SQL schema that needs to be inserted in order
     to function. These stops could either be performed by Ant,
     or scripts that could be executed by the proposed BSF
     (Bean Scripting Framework) service.
   </li>

   <li>
     Sub-applications will require a unique id to to keep things
     like templates in their own namespace. Eventually there
     may also be other entities that need to be kept separate.
     We could probably start a catalog of sub-applications to
     make sure that people don't use a unique id already being
     used by another sub-application in existence.
   </li>

   <li>
     Extension do DynamicURI and derivates to support new parameter
     (sub-application selector)
   </li>
 </ul>
 </section>


 <section name="Scope">
 <p>
 </p>
 </section>

 <section name="Initial Source">
 <p>
 </p>
 </section>

 <section name="Initial Committers">
 <p>
 </p>
 </section>

 </body>
 </document>
	<?xml version="1.0"?>
	<!--
	/*
	* Copyright 2001-2004 The Apache Software Foundation.
	*
	* Licensed under the Apache License, Version 2.0 (the "License");
	* you may not use this file except in compliance with the License.
	* You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing, software
	* distributed under the License is distributed on an "AS IS" BASIS,
	* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	* See the License for the specific language governing permissions and
	* limitations under the License.
	*/
	-->

	<document>

	<properties>
	<title>Application Service Proposal</title>
	</properties>

	<body>

	<section name="Description">
	<p>
	The application services would allow fully functional Turbine applications
	to be packaged up in the form of JAR files and deployed during Turbine
	startup.
	</p>
	</section>

	<section name="Rationale">
	<p>
	</p>
	</section>

	<section name="Requirements">
	<ul>
	<li>
	Turbine would probably process a directory of JAR files
	that contain sub-applications. The manifest would contain
	a set of instructions to be used by the application service
	so that the sub-application would be processed correctly
	and usable by Turbine. This may be the module.packages
	to add, or template paths to add, or whatever else is
	needed to bootstrap the sub-application.
	</li>

	<li>
	Module packages have to be dynamically configurable.
	The assembler broker must accept additional packages
	to look in for modules after the system has started.
	</li>

	<li>
	Must be able to load templates from JAR files. Velocity
	can do this, and it can probably be done for the other
	template services as well.
	</li>

	<li>
	Configuration information must be able to enter a
	running Turbine application. A sub application might
	have many forms of configuration info. It might be properties
	that have to be accessible via TurbineResources. Or
	it might configuration information to be used by one
	of the services, say for example an intake XML descriptor
	for the input forms used in the sub-application.
	<p/>
	The services in general might need some work to allow
	dynamic configuration so that sub-applications can
	really work properly.
	</li>

	<li>
	Sub-applications may require certain operations to be
	executed in order to run. This might be a forum application
	that has an SQL schema that needs to be inserted in order
	to function. These stops could either be performed by Ant,
	or scripts that could be executed by the proposed BSF
	(Bean Scripting Framework) service.
	</li>

	<li>
	Sub-applications will require a unique id to to keep things
	like templates in their own namespace. Eventually there
	may also be other entities that need to be kept separate.
	We could probably start a catalog of sub-applications to
	make sure that people don't use a unique id already being
	used by another sub-application in existence.
	</li>

	<li>
	Extension do DynamicURI and derivates to support new parameter
	(sub-application selector)
	</li>
	</ul>
	</section>


	<section name="Scope">
	<p>
	</p>
	</section>

	<section name="Initial Source">
	<p>
	</p>
	</section>

	<section name="Initial Committers">
	<p>
	</p>
	</section>

	</body>
	</document>