Package com.tccc.kos.commons.util.json.fragments

Class AppInfoFragment

java.lang.Object
com.tccc.kos.commons.util.json.fragments.AppInfoFragment
All Implemented Interfaces:
KosDescriptorFragment
public class AppInfoFragment extends Object implements KosDescriptorFragment
Bean representation of core app descriptor data so we can simply deserialize the object instead of extracting each field individually.
Since:
1.0
Version:
2023-01-03

  • Field Details

  • Constructor Details

    • AppInfoFragment

      public AppInfoFragment()

  • Method Details

    • getAppId

      public String getAppId()
      The unique application id for this application. Every application must have a globally unique id. The id is integrated into various KOS entities such as directory names, urls, topics and so on. An appId must contain only numbers, letters, underscores and periods. No other characters are allowed. Developers should pick id's that are namespaced to their organization (similar to java package names or domain names) to ensure no overlap with third party applications.

      Each KOS runtime can run a single system application. This KAB will have a type of kos.system and the appId must be system . If any other appId is used, the appId will be overwritten within KOS to be system . This ensures that all system app related paths and resources are consistent.

    • getAppClass

      public String getAppClass()
      The fully qualified class name for the Application class within the kab. This is used by KOS to create an instance of the application.

    • getClassesDir

      public String getClassesDir()
      An application can contain libraries and classes. By default KOS will search /classes in the KAB for any classes provided by the application. If there is a need to specify an alternate directory for classes within the KAB, override this value as needed.

    • getLibDir

      public String getLibDir()
      An application can contain libraries and classes. By default KOS will search /lib in the KAB for any jars provided by the application. If there is a need to specify an alternate directory for jars within the KAB, override this value as needed.

    • getTroubleInfoFile

      public String getTroubleInfoFile()

    • getTroubleInfoClass

      public String getTroubleInfoClass()

    • getSdkClassPrefixes

      public List<String> getSdkClassPrefixes()
      An application can have an associated sdk that allows thrid party developers compile against your application without access to the application code. KOS tooling provides a mechanism to annotate your code to automatically generate such an sdk. When a user of an sdk loads their application on KOS, it expects the actual implementation classes to be provided by your application. KOS provides a mechanism that allows your application to export these classes into the public classloader infrastructure while restricting all other classes. To expose your implementation classes, include the classes, or class prefixes in this list.

      Since sdk classes are shared among all loaded application in KOS, it is strongly recommended to use organization specific package names for your public facing classes to ensure there are no collisions with other third party apps that also expose an sdk.

    • setAppId

      public void setAppId(String appId)
      The unique application id for this application. Every application must have a globally unique id. The id is integrated into various KOS entities such as directory names, urls, topics and so on. An appId must contain only numbers, letters, underscores and periods. No other characters are allowed. Developers should pick id's that are namespaced to their organization (similar to java package names or domain names) to ensure no overlap with third party applications.

      Each KOS runtime can run a single system application. This KAB will have a type of kos.system and the appId must be system . If any other appId is used, the appId will be overwritten within KOS to be system . This ensures that all system app related paths and resources are consistent.

    • setAppClass

      public void setAppClass(String appClass)
      The fully qualified class name for the Application class within the kab. This is used by KOS to create an instance of the application.

    • setClassesDir

      public void setClassesDir(String classesDir)
      An application can contain libraries and classes. By default KOS will search /classes in the KAB for any classes provided by the application. If there is a need to specify an alternate directory for classes within the KAB, override this value as needed.

    • setLibDir

      public void setLibDir(String libDir)
      An application can contain libraries and classes. By default KOS will search /lib in the KAB for any jars provided by the application. If there is a need to specify an alternate directory for jars within the KAB, override this value as needed.

    • setTroubleInfoFile

      public void setTroubleInfoFile(String troubleInfoFile)

    • setTroubleInfoClass

      public void setTroubleInfoClass(String troubleInfoClass)

    • setSdkClassPrefixes

      public void setSdkClassPrefixes(List<String> sdkClassPrefixes)
      An application can have an associated sdk that allows thrid party developers compile against your application without access to the application code. KOS tooling provides a mechanism to annotate your code to automatically generate such an sdk. When a user of an sdk loads their application on KOS, it expects the actual implementation classes to be provided by your application. KOS provides a mechanism that allows your application to export these classes into the public classloader infrastructure while restricting all other classes. To expose your implementation classes, include the classes, or class prefixes in this list.

      Since sdk classes are shared among all loaded application in KOS, it is strongly recommended to use organization specific package names for your public facing classes to ensure there are no collisions with other third party apps that also expose an sdk.