Application Server - Revision history

Contributor1: /* Notes */

2025-09-22T10:27:30Z

Notes

← Older revision		Revision as of 10:27, 22 September 2025
Line 133:		Line 133:

	</syntaxhighlight>		</syntaxhighlight>

	== Notes ==

	# The <code>@enable</code> decorator can be applied multiple times to register different plugins.
	# Plugin options can configure ports, endpoints, or internal slots for routing.

	= HttpPlugin =		= HttpPlugin =

Contributor1: /* Plugin-based architecture */

2025-09-22T10:27:18Z

Plugin-based architecture

← Older revision		Revision as of 10:27, 22 September 2025
Line 93:		Line 93:

	# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.		# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
	# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options. The <code>@enable</code> decorator can be applied multiple times to register different plugins.		# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options. Plugin options can configure ports, endpoints, or internal slots for routing. The <code>@enable</code> decorator can be applied multiple times to register different plugins.
	# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.		# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.
	# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version. (you probably will call <code>super</code> to extend the functionality)		# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version. (you probably will call <code>super</code> to extend the functionality)

Contributor1: /* Plugin-based architecture */

2025-09-22T10:26:36Z

Plugin-based architecture

← Older revision		Revision as of 10:26, 22 September 2025
Line 93:		Line 93:

	# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.		# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
	# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.		# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options. The <code>@enable</code> decorator can be applied multiple times to register different plugins.
	# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.		# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.
	# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version. (you probably will call <code>super</code> to extend the functionality)		# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version. (you probably will call <code>super</code> to extend the functionality)

Contributor1: /* Plugin-based architecture */

2025-09-22T10:21:43Z

Plugin-based architecture

← Older revision		Revision as of 10:21, 22 September 2025
Line 95:		Line 95:
	# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.		# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
	# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.		# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.
	# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version.		# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version. (you probably will call <code>super</code> to extend the functionality)
	# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.		# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

Contributor1: /* Plugin-based architecture */

2025-09-22T10:16:30Z

Plugin-based architecture

← Older revision		Revision as of 10:16, 22 September 2025
Line 93:		Line 93:

	# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.		# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
	# '''~~Plugin~~ ~~Registration~~''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.		# '''Enabling a Plugin''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
	# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.		# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.
	# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version.		# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version.

Contributor1: /* Plugin-based architecture */

2025-09-22T10:15:54Z

Plugin-based architecture

← Older revision		Revision as of 10:15, 22 September 2025
Line 93:		Line 93:

	# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.		# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
	# '''Plugin Registration''': Plugins are ~~registered~~ using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.		# '''Plugin Registration''': Plugins are enabled using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
			# '''Plugin Enabling Order''': When enabling plugins with the <code>@enable</code> decorator, the order in which they are declared is important.
			# '''Class-Based Plugin Implementation''': In practice, plugins extend your new server class from bottom to top. The last declared plugin will be the closest descendant of your class, while the first declared plugin will be the farthest down in the chain. This also means that if you define a method in your own class with the same name as one provided by a plugin, your method will override the plugin’s version.
	# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.		# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

Guttmann: /* Request and Response Handling */

2025-09-22T05:38:05Z

Request and Response Handling

← Older revision		Revision as of 05:38, 22 September 2025
Line 171:		Line 171:
	/* @babel ES2025 */		/* @babel ES2025 */

	import {Server, ~~use~~} from "appserver";		import { Server, enable } from "appserver";
	import {~~AppServerPlugin~~} from "appserver";		import { ApplicationServer } from "appserver";
	import {~~SystemdPlugin}~~ from "appserver";		import { HttpServer, http } from "appserver";
	import {~~HttpPlugin~~, ~~http~~} from "appserver";		import { AuthenticationService, auth } from "appserver";
	import {~~AuthPlugin~~, ~~auth}~~ from "appserver";		import { PermissionManager, perm } from "appserver";
	import {~~PermPlugin,~~ ~~perm~~} from "appserver";		import { SystemdIntegration } from "appserver";
	import {~~DebugConsolePlugin~~} from "appserver";		import { HAProxyIntegration } from "appserver";
	import {~~HAProxyPlugin~~} from "appserver";		import { ApplicationConsole } from "appserver";


			@enable( ApplicationConsole )
	@use( DebugConsolePlugin )
	@~~use~~( ~~HAProxyPlugin~~, {port: 8080, endpoint: /^(?!.\.jss$)./, slot: "http_slot00"} )		@enable( HAProxyIntegration, {port: 8080, endpoint: /^(?!.\.jss$)./, slot: "http_slot00"} )
			@enable( SystemdIntegration )
	@use( SystemdPlugin )
	@~~use~~( ~~HttpPlugin~~, {port: 8080} )		@enable( HttpServer, {port: 8080} )
			@enable( ApplicationServer )
	@use( AppServerPlugin )
			@enable( AuthenticationService )
	@use( AuthPlugin )
			@enable( PermissionManager )
	@use( PermPlugin )
	class MyServer extends Server {		class MyServer extends Server {

Guttmann: /* Notes */

2025-09-22T05:37:29Z

Notes

← Older revision		Revision as of 05:37, 22 September 2025
Line 134:		Line 134:
	== Notes ==		== Notes ==

	# The <code>@~~use~~</code> decorator can be applied multiple times to register different plugins.		# The <code>@enable</code> decorator can be applied multiple times to register different plugins.
	# Plugin options can configure ports, endpoints, or internal slots for routing.		# Plugin options can configure ports, endpoints, or internal slots for routing.

Guttmann: /* Plugin-based architecture */

2025-09-22T05:37:10Z

Plugin-based architecture

← Older revision		Revision as of 05:37, 22 September 2025
Line 93:		Line 93:

	# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.		# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
	# '''Plugin Registration''': Plugins are registered using the <code>@~~use~~</code> decorator, which associates a plugin class with optional configuration options.		# '''Plugin Registration''': Plugins are registered using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
	# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.		# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

Line 100:		Line 100:
	/* @babel ES2025 */		/* @babel ES2025 */

	import {Server, ~~use~~} from "appserver";		import { Server, enable } from "appserver";
	import {~~AppServerPlugin~~} from "appserver";		import { ApplicationServer } from "appserver";
	import {~~SystemdPlugin}~~ from "appserver";		import { HttpServer, http } from "appserver";
	import {~~HttpPlugin~~, ~~http~~} from "appserver";		import { AuthenticationService, auth } from "appserver";
	import {~~AuthPlugin~~, ~~auth}~~ from "appserver";		import { PermissionManager, perm } from "appserver";
	import {~~PermPlugin,~~ ~~perm~~} from "appserver";		import { SystemdIntegration } from "appserver";
	import {~~DebugConsolePlugin~~} from "appserver";		import { HAProxyIntegration } from "appserver";
	import {~~HAProxyPlugin~~} from "appserver";		import { ApplicationConsole } from "appserver";


			@enable( ApplicationConsole )
	@use( DebugConsolePlugin )
	@~~use~~( ~~HAProxyPlugin~~, {port: 8080, endpoint: /^(?!.\.jss$)./, slot: "http_slot00"} )		@enable( HAProxyIntegration, {port: 8080, endpoint: /^(?!.\.jss$)./, slot: "http_slot00"} )
			@enable( SystemdIntegration )
	@use( SystemdPlugin )
	@~~use~~( ~~HttpPlugin~~, {port: 8080} )		@enable( HttpServer, {port: 8080} )
			@enable( ApplicationServer )
	@use( AppServerPlugin )
			@enable( AuthenticationService )
	@use( AuthPlugin )
			@enable( PermissionManager )
	@use( PermPlugin )
	class MyServer extends Server {		class MyServer extends Server {

Line 128:		Line 128:

	}		}


	</syntaxhighlight>		</syntaxhighlight>

Guttmann: /* Supported Decorators */

2025-09-19T16:36:07Z

Supported Decorators

← Older revision		Revision as of 16:36, 19 September 2025
Line 155:		Line 155:
	* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.		* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
	* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.		* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

			The path may be a string for an exact match or a RegExp for flexible matching.

	== Request and Response Handling ==		== Request and Response Handling ==