wer

a

Author: kaspernielsen

BigTasks.txt

@@ -0,0 +1,36 @@
+
+-- Clarification
+Build - Order
+
+BuildHooks
+  onClose(), onConfigured();
+  
+Extension Ordering, when can they install shit
+
+// Assembly
+
+
+
+
+----- app.packed.application ----
+BaseImage.result
+ApplicationConfiguration
+ApplicationRepository
+
+----- app.packed.build ----
+Cleanup hooks
+
+----- app.packed.binding ----
+Cleanup bindings
+Figure out how binding-handles work 
+
+
+----- app.packed.namespace -----
+
+
+
+
+---- Modules
+packed-base
+packed-base-devtools   <---- Testing
+packed-base-devops     <---- What went wrong, Observability

architecture/build/hooks/Functionality.txt

@@ -0,0 +1,7 @@
+What rights does a build hook have???
+
+Can it do something then owner of the component cannot???
+Meaning can it do something only an extension would normally be able to?
+
+--
+I think it must be owned focused

architecture/build/order/BuildOrder.txt

@@ -0,0 +1,35 @@
+In what order is everything build.
+
+
+Principals
+* Must be deterministic
+* Must give good error messages
+* Must provide an easy way to shutdown
+* Must be explainable
+
+
+Actors
+  User, Extension, Framework
+
+BuildCodeSource
+  Assembly, Extension, BuildHook
+
+Lifecycle
+  Application, Container, Bean, Operation, Namespace, Binding
+
+Other
+  ComponentHandle, ComponentConfiguration
+
+// onClose, onConfigured
+
+-- Clarification
+Build - Order
+
+Component/Extension/Assembly
+  onClose(), onConfigured();
+  
+Extension Ordering, when can they install shit
+
+
+* When can extensions install stuff
+* How are build hooks applied and ordered

architecture/build/order/Givens.txt

@@ -0,0 +1,15 @@
+
+Extension, ApplicationHandle, ContainerHandle, NamespaceHandle, BeanHandle, OperationHandle
+
+
+onConfigured() is always executed before onClosed()
+
+operation.onClose() is invoked before bean.onClose()
+bean.onClose() is invoked before container.onClose();
+
+container.onClose() is invoked before application.onClose()
+namespace.onClose() is invoked before application.onClose()
+
+
+
+extension.onClose is invoked after all namespaces that is owns has been shutdown

architecture/build/order/OpenQuestions.txt

@@ -0,0 +1,7 @@
+Can an operation be added after Bean.OnConfigured?
+
+Jeg tror simpelthen alle hooks er koert nar vi begynder paa det..
+
+Saa er det kun extensions vi skal bekymre os om, og ikke brugeren
+
+Hmm nej

architecture/build/order/Various.txt

@@ -0,0 +1,4 @@
+Assembly
+
+  beforeAnyBeansAreInstalled
+  beforeAnyExtensionsAreConfigured

architecture/build/order/ops.txt

@@ -0,0 +1,33 @@
+Operation
+  NewOperation     [OperationBuildHook] <- Before being returned to the extension actually
+  OnClosing        [OperationBuildHook] <- Going to mark it as unconfigureable
+  OnConfigured     [OperationHandle]    <- The 
+  OnClosed         [OperationHandle]
+[ApplicationFinishedBuilding]  
+  Verify           [OperationBuildHook] <- Verify is maybe not the best word...
+  
+  
+Lifecycle
+  OperationHandle is created, OperationConfiguration is created
+  hooks.onNew(Configuration)
+  
+  operation.onConfigured
+    hooks.onClosing(Configuration)
+    handle.onConfigured();
+    
+  operation.onClose();
+  
+  hooks.onBuildSuccess  
+
+----
+Problemet med at tillade at installere operation for beanen efter alle operation.onConfigured.
+Er at nu tilfoejer vi en operation for en bean der ikke laengere er configurable...
+Det er lidt noget moej, har vi brug for dette?
+Tror ikke man kan installere flere operation for en bean efter den er onConfigured
+
+bean.onConfigured
+forAllOperations.onConfigured
+  onConfigured
+bean.state=OnConfigured=true <- Can no longer add operations
+
+// Bruger kalder onConfigured() { WebExtension.AddFake() stuff that needs to add operations to all beans}

architecture/namespace/Namespaces.md

@@ -0,0 +1,15 @@
+# Overview
+
+A namespace manages 1 or more resources, is an object that trans.
+
+Thread namespaces are not supported by unmanaged applications.
+A managed application always has at least 1 thread namespace (owned by the user) in order to support 
+multiple threaded startup and shutdown.
+
+# Truths
+Vi bliver noedt til at supportere shutdown asynchronous,
+  Ville vaere maerkeligt, hvis man fx kalder .shutdown() indefra en starting metode.
+  Som saa begynder at koere alt stop koden, mens vi stadig er i start koden
+ 
+
+1 Shared ThreadNamespace

architecture/namespace/base/ThreadNamespace.md

@@ -0,0 +1,15 @@
+# Overview
+
+A Thread namespace manages all threads and thread pools, creation and termination of the threads when an application is shutdown.
+
+Thread namespaces are not supported by unmanaged applications.
+A managed application always has at least 1 thread namespace (owned by the user) in order to support 
+multiple threaded startup and shutdown.
+
+# Truths
+Vi bliver noedt til at supportere shutdown asynchronous,
+  Ville vaere maerkeligt, hvis man fx kalder .shutdown() indefra en starting metode.
+  Som saa begynder at koere alt stop koden, mens vi stadig er i start koden
+ 
+
+1 Shared ThreadNamespace

architecture/operation/invoker/TypedInvoker.txt

@@ -0,0 +1,12 @@
+Ideen er at vi ikke exposer MethodHandle + ExtensionContext til en extension.
+
+Istedet for for en extension injected en invoker[] i en bean af eget valg.
+
+// Saa vi skal instantiere et array hver gang (StableValue??)
+
+
+? Hvordan faar dem knyttet Invokeren til en Bean
+
+Man maa angive beanen naar man registere invokeren...
+
+? Skal den vaere i samme lifetime? mhhm nej. Jo, eller ogsaa skal den lave i lifetime i operationen...