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

Class AppInfoFragment

java.lang.Object
com.kosdev.kos.commons.util.json.fragments.AppInfoFragment
All Implemented Interfaces:
KosDescriptorFragment
public class AppInfoFragment extends Object implements KosDescriptorFragment
Standard information about an application encoded into descriptor.json within a KAB of type kos.app or kos.system. The fields of this object describe details about the application and how to properly load it within KOS.
Since:
1
Version:
1

  • Field Summary

    Fields
    Modifier and Type
    Field
    Description
    static final String
    PATH
    Path to where this AppInfoFragment object exists in a standard KOS descriptor.json file: kos.app .

  • Constructor Summary

    Constructors
    Constructor
    Description
    AppInfoFragment()
     

  • Method Summary

    Modifier and Type
    Method
    Description
    int
    getApiVersion()
    The api version supported by this app.
    String
    getAppClass()
    The fully qualified class name for the Application class within the kab.
    String
    getAppId()
    The unique application id for this application.
    String
    getClassesDir()
    An application can contain libraries and classes.
    String
    getLibDir()
    An application can contain libraries and classes.
    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.
    void
    setApiVersion(int apiVersion)
    The api version supported by this app.
    void
    setAppClass(String appClass)
    The fully qualified class name for the Application class within the kab.
    void
    setAppId(String appId)
    The unique application id for this application.
    void
    setClassesDir(String classesDir)
    An application can contain libraries and classes.
    void
    setLibDir(String libDir)
    An application can contain libraries and classes.
    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.

    Methods inherited from class java.lang.Object

    equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Field Details

    • PATH

      public static final String PATH
      Path to where this AppInfoFragment object exists in a standard KOS descriptor.json file: kos.app .
      See Also:

  • 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.

    • getApiVersion

      public int getApiVersion()
      The api version supported by this app. Unlike the version of the app, this describes the compatibility of the api. If the api version of the app is the same as the api version of the sdk, the version of the app shouldn't matter as the api's haven't changed. This can also be used to dynamically determine which api's to call based on the supported api version.

      This is subject to app development teams supporting the use of api versions. When a api version changes, users must consult the app vendor to determine the nature of the changes. Developers may choose to use semantic versions for their apps to indicate compatibility, but in cases where that's not the case, api version is another available alternative.

    • 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.

    • 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.

    • setApiVersion

      public void setApiVersion(int apiVersion)
      The api version supported by this app. Unlike the version of the app, this describes the compatibility of the api. If the api version of the app is the same as the api version of the sdk, the version of the app shouldn't matter as the api's haven't changed. This can also be used to dynamically determine which api's to call based on the supported api version.

      This is subject to app development teams supporting the use of api versions. When a api version changes, users must consult the app vendor to determine the nature of the changes. Developers may choose to use semantic versions for their apps to indicate compatibility, but in cases where that's not the case, api version is another available alternative.

    • 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.

    • 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.