JP2021189487A - 管理装置およびその制御方法 - Google Patents
管理装置およびその制御方法 Download PDFInfo
- Publication number
- JP2021189487A JP2021189487A JP2020090827A JP2020090827A JP2021189487A JP 2021189487 A JP2021189487 A JP 2021189487A JP 2020090827 A JP2020090827 A JP 2020090827A JP 2020090827 A JP2020090827 A JP 2020090827A JP 2021189487 A JP2021189487 A JP 2021189487A
- Authority
- JP
- Japan
- Prior art keywords
- application
- file
- management device
- combined
- determined
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】アプリケーションによるファイルディスクリプタの消費を低減する。【解決手段】情報処理装置上で動作する複数のアプリケーションを管理する管理装置は、アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、従属アプリケーションと判定された第1アプリケーションと、独立アプリケーションと判定されかつ第1アプリケーションが紐づく第2アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、を有する。【選択図】図5
Description
本発明は、アプリケーションによるファイルディスクリプタの消費を低減する技術に関するものである。
Java(登録商標)の実行環境において、クラス(実行に必要なコード)のロードはクラスローダによって行われる。クラスは、JAR(Java Archive)形式のファイル(JARファイル)の中にあるクラスファイルで定義されている。Javaの実行環境では、パフォーマンスを向上させるため、一度参照したJARファイルは、実行環境上で動作するプログラムが終了するまで参照され続ける。そのため、クラスローダがJARファイルを参照するために消費したファイルディスクリプタはプログラムが終了するまで消費され続けることになる。
組込機器においては、アプリケーションプログラム(以降アプリケーションと呼ぶ)の実行環境において使用可能なリソースに制限がある。例えば、リソースの1種であるファイルディスクリプタも、使用可能なファイルディスクリプタ数に制限がある。そのため、開発者はアプリケーションが使用するリソース量について予め上限値を設定することがある。これにより、アプリケーションの実行する際にアプリケーション管理フレームワークは設定された上限値に基づいて使用可能なリソース量を超えるか否かを確認することができる。また、例えば特許文献1には、リソース上限を超えると判定された場合に、アプリケーションに含まれるライブラリ(JARファイル)を統合してからアプリケーションを実行する技術が開示されている。
しかしながら、特許文献1に記載の技術ではアプリケーションに含まれるライブラリを統合する構成であるため、クラスを含まないアプリケーションでは効果がないという課題がある。また、インストールされるアプリケーション数が増えると、アプリケーション数分のファイルディスクリプタは必ず消費してしまうという問題がある。
本発明は、このような問題に鑑みてなされたものであり、ファイルディスクリプタの消費を低減可能とするアプリケーション管理技術を提供することを目的としている。
上述の問題点を解決するため、本発明に係る管理装置は以下の構成を備える。すなわち、情報処理装置上で動作する複数のアプリケーションを管理する管理装置は、
アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、
前記判定手段により従属アプリケーションと判定された第1アプリケーションと、前記判定手段により独立アプリケーションと判定されかつ前記第1アプリケーションが紐づく第2アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、
有する。
アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、
前記判定手段により従属アプリケーションと判定された第1アプリケーションと、前記判定手段により独立アプリケーションと判定されかつ前記第1アプリケーションが紐づく第2アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、
有する。
本発明によれば、ファイルディスクリプタの消費を低減可能とするアプリケーション管理技術を提供することができる。
以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。
(第1実施形態)
本発明に係る管理装置の第1実施形態として、仮想化された情報処理装置であるJava(登録商標)仮想マシン(VM:Virtual Machine)を搭載した画像形成装置を例に挙げて以下に説明する。
本発明に係る管理装置の第1実施形態として、仮想化された情報処理装置であるJava(登録商標)仮想マシン(VM:Virtual Machine)を搭載した画像形成装置を例に挙げて以下に説明する。
<装置構成>
図1は、第1実施形態に係る画像形成装置のハードウェア構成を示す図である。画像形成装置100は、コア部101、ユーザインタフェース部102、記憶装置103、ネットワークインタフェース部104、スキャナ部105、プリンタ部106、フィニッシャ部107を含む。
図1は、第1実施形態に係る画像形成装置のハードウェア構成を示す図である。画像形成装置100は、コア部101、ユーザインタフェース部102、記憶装置103、ネットワークインタフェース部104、スキャナ部105、プリンタ部106、フィニッシャ部107を含む。
コア部101は、記憶装置103に格納されているファームウェアを呼び出して実行することで画像形成装置100の基本機能を提供する。ファームウェアが提供する基本機能としては、コピー機能、送信機能、アプリケーション管理機能等が挙げられる。アプリケーション管理機能は、外部ネットワーク108やUSBメモリ等を経由してアプリケーションを取得して画像形成装置100内にインストールすることにより画像形成装置100で利用可能な機能を追加する。アプリケーションは、コア部101で実行され、ユーザインタフェース部102〜フィニッシャ部107を制御することで様々な機能をユーザに提供する。
ユーザインタフェース部102は、メインメニュー画面や各種アプリケーションの設定画面を表示したり、ユーザ操作からの入力を受け付けたりする。記憶装置103は、ファームウェアやアプリケーションを格納するための装置である。また、記憶装置103は、各種アプリケーションの設定情報の格納も行う。ネットワークインタフェース部104は、外部ネットワーク108に接続するためのインタフェースである。
スキャナ部105は、原稿を読み取り画像データを生成するための装置である。プリンタ部106は、画像データに基づく画像を用紙などの記録媒体に印刷するための装置である。フィニッシャ部107は、出力した用紙に対して各種フィニッシング処理を行うための装置である。
図2は、アプリケーションの実行に係るソフトウェアの機能構成を示す図である。より具体的には、画像形成装置100で動作するアプリケーション管理機能をブロック図で示したものである。画像形成装置は、情報処理装置上(JavaVM上)でJavaアプリケーションプログラムを実行するすることにより様々な機能を提供することが出来る。
JavaVM200は、JavaVMであり、Javaプログラムを動作させるための実行モジュールである。アプリフレームワーク201は、アプリケーションを動作させるためのフレームワークであり、アプリ管理部202、マージ制御部203、認証制御部204、画面制御部205、デバイス制御ライブラリ206から構成される。
アプリ管理部202は、アプリケーションのインストール(追加)・アンインストール(削除)・開始・停止などのライフサイクル制御を行う。また、画像形成装置上で使用可能なファイルディスクリプタの上限(所定の上限値)を保持し、アプリケーションのファイルディスクリプタ使用数の合計が利用可能上限を超えないようにアプリケーションの起動制御を行う。マージ制御部203は、アプリ管理部202からの要求を受けてアプリケーションファイルの結合(以降マージと呼ぶ)や復元(以降リストアと呼ぶ)を行う。
認証制御部204は、ユーザ認証を行うための機能を備え、アプリケーションからログイン中のユーザの情報を取得する手段を提供する。画面制御部205は、ユーザインタフェース部102へのアプリケーションの表示制御を行う。初期状態ではユーザ認証画面を表示し、ユーザからの認証情報入力を受け付け、認証制御部により認証された場合にアプリケーション207の画面に切り替える。
デバイス制御ライブラリ206は、アプリフレームワーク201上で動作するアプリケーション207からユーザインタフェース部102〜フィニッシャ部107を制御するためのAPI群である。
アプリケーション207は、追加や削除することが可能なアプリケーションであり、デバイス制御ライブラリ206のAPIを呼び出すことによりユーザに対してさまざまな拡張機能を提供する。アプリケーション207には、ホストアプリケーション208、フラグメントアプリケーション209の2種類の異なる種類のアプリケーションが存在する。
ホストアプリケーション208は、単独で動作可能なアプリケーション207である。ホストアプリケーションは独立アプリケーションとも呼ばれる。例えば、スキャンして外部サーバに送信するアプリケーションや、ユーザが投入した印刷ジョブの一覧を表示して選択されたジョブを印刷するアプリケーションなどがあげられる。
フラグメントアプリケーション209は、ホストアプリケーション208の機能を拡張するためのアプリケーションであり、単体では動作せずホストアプリケーション208に紐づいてのみ動作可能なアプリケーションである。フラグメントアプリケーションは従属アプリケーションとも呼ばれる。例えば、送信を行うようなホストアプリケーション208において、選択可能な送信先を増やしたり、UIの表示言語を拡張したりする。一つのホストアプリケーション208に対して複数のフラグメントアプリケーション209を追加して機能拡張を行うことも可能である。
クラスローダ210は、Javaプログラムをロードするためのモジュールであり、ブートクラスローダ211、システムクラスローダ212、アプリクラスローダ213の3種類が存在する。ブートクラスローダ211は、Javaの標準クラスをロードするためのクラスローダである。システムクラスローダ212は、アプリフレームワーク202のJavaプログラムをロードするためのクラスローダである。アプリクラスローダ213は、後から追加されたアプリケーション207のプログラムをロードするためのモジュールである。なお、アプリクラスローダ213はホストアプリケーション207毎に別々のクラスローダが割り当てられる。
なお、フラグメントアプリケーション209は、親となるホストアプリケーション208に対応したアプリクラスローダ213を使ってクラスロードされるため、フラグメントアプリケーション用のアプリクラスローダは用意されない。また、クラスロードの優先順位はホストアプリケーションよりもフラグメントアプリケーションが優先される。これによりフラグメントアプリケーションを追加することでホストアプリケーションの機能を差し替えたり拡張したりすることが容易になっている。
図3Aは、後述するマージ処理前のアプリケーションのファイル配置の例を示す図である。また、図中の矢印はクラスローダがどのJARファイルを開くかを模式的に示している。図3Aでは、3つのホストアプリケーション(ホストアプリA〜C)と2つのフラグメントアプリケーション(フラグメントA1〜A2)がインストールされている構成の例を示している。
領域301は、JavaVMのシステムのファイルが保存される領域であり、ここに配置されたファイルはブートクラスローダ211によってロードされる。領域302は、アプリフレームワーク202の各種JARファイルが配置される領域である。ここに配置されたファイルはシステムクラスローダ212からローダされる。領域303は、アプリケーションのファイルが格納される領域である。
アプリケーションがインストールされると、そのアプリケーション用のディレクトリが作られ、その下にファイルが配置される。また、インストールされたアプリケーションが、ホストアプリケーション208の場合は、新たなアプリクラスローダが割り当てられる。フラグメントアプリケーション209の場合は、新たなアプリクラスローダは割り当てられず、対応するホストアプリケーション208のクラスローダが使われる。
ブートクラスローダ211およびシステムクラスローダ212は、画像形成装置の起動時にLib以下にあるすべてのJARファイルを開いた状態となる。アプリクラスローダ213は、アプリケーションを起動するタイミングでJARファイルを開く。
全てのクラスローダは一度ロード対象のJARファイルをオープンすると常にオープンするようになっており、クローズすることはない。そのため、動作させるアプリケーション数の増加に伴いファイルのオープン数も増える。例えば、ホストアプリケーションを10種類インストールして開始した状態で、それぞれに対して言語拡張のためのフラグメントアプリケーションを30種類ずつ存在するような場合、アプリクラスローダだけで300ファイルを常にオープンする状態となる。
図3Bは、フラグメントアプリケーション209をホストアプリケーション208にマージした後の結合アプリケーションを含むファイルの配置を示す図である。図3Bでは、ホストアプリAとプラグ面とA1とフラグメントA2とをマージした結合アプリケーションである「ホストアプリA+フラグメント1/2.jar」が例示されている。Backup304は、ホストアプリケーションのマージする前のオリジナルファイルを残すためのディレクトリである(以降バックアップディレクトリと記す)。ここに保存されたファイルは、マージしたファイルをアンインストールする場合に、JARファイルを元の状態に戻すために利用される。なお、別の結合アプリケーションである「ホストアプリB+C.jar」も例示されているが、これについては第2実施形態において説明する。
フラグメントアプリケーション(フラグメントA1〜A2)のJARファイルはアプリケーション毎のディレクトリに残っている。ただし、アプリクラスローダ213がこれらのJARファイルを開くことがなくなるためファイルのオープン数(ファイルディスクリプタ使用数)が削減される。なお、ここでは説明を簡単にするためにマージする側やマージされる側のファイルをそのまま残す構成としているが、各ファイル構成情報および復元に必要な必要最低限のファイルだけを保存するようにしてもよい。
図4は、属性定義ファイルの例を示す図である。属性定義ファイルは、アプリケーションの属性情報を定義するファイルである。図4(a)はホストアプリケーションの属性情報の一例を、図4(b)はフラグメントアプリケーションの属性情報の一例を、それぞれ示している。
App−Id401は、アプリケーションを一意に識別するための識別情報であり、他のアプリケーションと重複しない値が設定される。ここではApp−Idは8桁の英数字としているが、UUIDであってもよい。App―Activator402はホストアプリケーションを起動する際のクラス名である。アプリ管理部202がアプリケーションを起動する際にここに記載されたクラスのメソッドを実行することでアプリケーションの処理を開始する。なお、この属性はホストアプリケーションのみに存在するため、この属性が存在すればホストアプリケーションであると判断できる。
App−Vendor403はアプリケーションの開発元を示す。App−Name404はアプリケーションの名前を示す。MaximumFiledescriptorUsage405は、そのアプリケーションを利用した際に同時に使用される最大ファイルディスクリプタ数を示す。Locales406は、そのアプリケーションが対応している言語を示す。
HostApp407は、そのフラグメントアプリケーションが紐づくホストアプリケーションのApp−Idを示す属性である。この属性はフラグメントアプリケーションにしか存在しないためこの属性があればフラグメントアプリケーションであると判断できる。
表1は、アプリ管理部202が、アプリケーションを管理する際のアプリ管理テーブルの例である。
アプリ管理部202は、アプリケーションのインストールが行われる際に、アプリケーションに含まれる属性定義ファイルを読みだしてテーブルに情報を追加する。また、アンインストールされる際に、テーブルから情報を削除する。また、アプリケーションを開始したり停止したりJARファイルをマージしたりリストアしたりするタイミングでこのテーブル内の情報を更新する。アプリ管理テーブルの情報は不揮発メモリに保存され、デバイス再起動時にこの情報を読み込むことにより再起動前の状態に復帰する。
App−Id〜HostAppまでの列はアプリケーションインストール時に属性定義ファイル(図4)を読み取って設定が行われる。MaxfdUsageは、アプリ属性のMaximumFiledescriptorUsageを読み取って設定されるが、アプリケーションファイルをマージしたりリストアしたりするタイミングで値が更新される。Typeは、アプリケーションの種類を示す情報である。App−Activatorの属性があればホストアプリケーションを示す“H”が設定され、HostAppの属性があればフラグメントアプリケーションを示す“F“が設定される。
Statusは、アプリケーションの状態を示す。アプリケーションを実行(開始)している場合は「開始」状態に、停止している場合は「停止」状態となる。なお、クラスローダがJARファイルをオープンするのはアプリケーションを開始した時であり、停止中のアプリケーションについてはファイルがオープンされない。また状態を持つのはホストアプリケーションのみであり、フラグメントアプリケーションは対応するホストアプリケーションの状態に準ずる。よって、対応するホストアプリケーションが開始状態であればフラグメントアプリケーションのJARファイルもオープンされる。また、ホストアプリケーションが停止状態であればフラグメントアプリケーションのJARファイルはオープンされない。なお、開始状態のホストアプリケーションにフラグメントアプリケーションを追加するとすぐにJARファイルが開かれファイルディスクリプタを消費することになる。
InstallPathは、そのアプリケーションをインストールしたパスを示す。MergedFlagは、そのアプリケーションのJARファイルが他のアプリケーションのJARファイルとマージされているか否かを示すフラグである。MergePathは、そのアプリケーションがマージされている場合に、どのパスのJARファイルにマージされているのかを示す情報である。もしMergePathとInstallPathが等しい場合は、他のアプリケーションのJARファイルがそのアプリケーションのJARファイルにマージされていることを意味する。
表2は、Sendアプリケーションに対してマージ処理を行った後のアプリ管理テーブルの例を示す。
ここでは、2つのフラグメントアプリケーション「Send_fr」および「Send_ja」をホストアプリケーション「Send」にマージした場合の例を示している。そのため、これら3つに対するMergeFlagがTrueに設定され、MergePathは/App/aaaに設定される。また、Send_frおよびSend_jaはマージされることで元のJARファイルは開かれなくなりファイルディスクリプタが消費されなくなるため、MaxFdUsageの値が−1されて「0」になる。
<装置の動作>
図5は、アプリケーションをインストールする際の処理を示すフローチャートである。当該処理は、アプリ管理部202が、アプリケーションのインストール要求を受信することにより実行開始される。
図5は、アプリケーションをインストールする際の処理を示すフローチャートである。当該処理は、アプリ管理部202が、アプリケーションのインストール要求を受信することにより実行開始される。
ステップS501では、アプリ管理部202は、アプリケーションのインストール要求を受けると、要求されたアプリケーションをインストールする。ステップS502では、アプリ管理部202は、アプリケーションの使用リソース(ここでは使用ファイルディスクリプタ数)の合計が、画像形成装置の使用可能ファイルディスクリプタ数の上限(所定の上限値)を超えているかをリソース判定する。上限を超えていないと判定した場合は処理を終了し、上限を超えていると判定した場合はS503に進む。
ステップS503では、アプリ管理部202は、インストールしたアプリケーションの種類を判定する。具体的にはアプリ管理テーブルのTypeの情報を参照して判定する。フラグメントアプリケーションであると判定した場合はS504に進み、ホストアプリケーションであると判定した場合はS507に進む。
ステップS504では、アプリ管理部202は、インストールしたフラグメントアプリケーションをマージした場合のアプリケーション(つまり結合アプリケーション)の使用ファイルディスクリプタ数の合計を算出する。そして、合計が、画像形成装置で利用可能なファイルディスクリプタ数の上限を超えているかを判定する。上限を超えていないと判定した場合はS505に進み、上限を超えていると判定した場合はS506に進む。
ステップS505では、アプリ管理部202は、インストールしたフラグメントアプリケーションをホストアプリケーションにマージして処理を終了する。マージ処理の詳細は図7を参照して後述する。
ステップS506では、アプリ管理部202は、対象のアプリケーションの識別情報をマージ対象リストに追加する。ここではフラグメントアプリケーションとホストアプリケーションの識別子の組を追加する。なお、マージ対象リストはどのアプリケーションをどのアプリケーションにマージするかの情報を保持するためのリストである。
ステップS507では、アプリ管理部202は、S505でマージしたフラグメントアプリケーション以外の、インストールされている未マージ状態のフラグメントアプリケーションが存在するかを判定する。未マージ状態のフラグメントがあると判定した場合はS508に進み、未マージ状態のフラグメントアプリケーションがないと判定した場合はS511に進む。
ステップS508では、アプリ管理部202は、S507での判定時に特定したフラグメントアプリケーション情報をマージ対象リストに追加する。ステップS509では、アプリ管理部202は、マージ対象リストに存在するアプリケーションをマージした場合のファイルディスクリプタ使用数の合計を算出する。そして、合計が、画像形成装置で利用可能なファイルディスクリプタ数の上限を超えているかを判定する。上限を超えていると判定した場合はS507に進み、上限を超えていないと判定した場合はS510に進む。
ステップS510では、アプリ管理部202は、マージ対象リストに記載されたアプリケーションの識別情報をもとにマージ処理を行い、処理を終了する。一方、ステップS511では、アプリ管理部202は、S501でインストールしたアプリケーションをアンインストールしてインストールエラーを返し、処理を終了する。
図6は、アプリケーションをアンインストールする際の処理を示すフローチャートである。当該処理は、アプリ管理部202が、アプリケーションのアンインストール要求を受信することにより実行開始される。
ステップS601では、アプリ管理部202は、アンインストール対象のアプリケーションの種別を判定する。ホストアプリケーションであると判定した場合はS602に進み、フラグメントアプリケーションであると判定した場合はS607に進む。
ステップS602では、アプリ管理部202は、アンインストール対象のホストアプリケーションに対応するフラグメントアプリケーションが存在するか否かを判定する。フラグメントアプリケーションが存在すると判定した場合はS603に進み、存在しないと判定した場合はS604に進む。
ステップS603では、アプリ管理部202は、アンインストールエラーを返し処理を終了する。なお、ここではフラグメントアプリケーションが存在する場合は事前にフラグメントアプリケーションをアンインストールしておかないとホストアプリケーションをアンインストールできない仕様を想定している。
ステップS604では、アプリ管理部202は、アンインストール対象のアプリケーションがマージ済みであるかどうかをアプリ管理テーブルのMergeFlagを参照して判定(結合判定)する。もしマージ済みであると判定した場合はステップS605に進み、マージ済みでないと判定した場合はステップS606に進む。ステップS605では、アプリ管理部202は、アンインストール対象のホストアプリケーションのリストア処理を行う。リストア処理の詳細は図8を参照して後述する。ステップS606では、アプリ管理部202は、要求されたホストアプリケーションをアンインストールして処理を終了する。
ステップS607では、アプリ管理部202は、アンインストール対象のフラグメントアプリケーションがホストアプリケーションにマージ済みであるかを判定する。もしマージ済みであると判定した場合はS608に進み、マージ済みでないと判定した場合はS609に進む。ステップS608では、アプリ管理部202は、フラグメントアプリケーションのリストア処理を行う。ステップS609では、アプリ管理部202は、フラグメントアプリケーションをアンインストールして処理を終了する。
図7は、ファイルのマージ処理(S505、S510)を説明するフローチャートである。なお、マージ処理の呼び出し元からはマージ対象のアプリケーションの識別情報が渡されてくるものとする。ここではマージ元のフラグメントアプリケーションを「アプリケーションA」、マージ先のホストアプリケーションを「アプリケーションB」と呼ぶ。
ステップS701では、マージ制御部203は、アプリ管理部202からマージ処理要求を受けると、アプリケーションBのオリジナルのJARファイルが退避済みかを判断する。具体的には、アプリケーションBのインストールパスの下のバックアップディレクトリにJARファイルが存在していれば退避済みであると判定する。S701において退避済みでないと判定した場合はS702に進み、退避済みであると判定した場合はS703に進む。
ステップS702では、マージ制御部203は、アプリケーションBのJARファイルをバックアップディレクトリにコピーしてステップS703に進む。
ステップS703では、マージ制御部203は、アプリケーションAのJARファイルに含まれるファイルをアプリケーションBのJARファイルに追加する。この際、アプリケーションAの属性定義ファイル以外のファイルを追加する。もしファイルの重複があった場合は、フラグメントアプリケーションのファイルが使われるようにするため、アプリケーションBのファイルをアプリケーションAのファイルに上書きする。
ステップS704では、マージ制御部203は、管理テーブルの内容を更新する。具体的には、アプリケーションAの情報に関して、MergeFlagを「True」に設定し、MaxFdUsageの値を−1した値に設定する。また、MergePathにアプリケーションBのインストールパスを設定する。さらに、アプリケーションBの情報に関して、MergeFlagを「True」に設定し、MergePathにアプリケーションBのインストールパスを設定する。
図8は、ファイルのリストア処理(S605、S608)を説明するフローチャートである。なお、リストア処理の呼び出し元からはリストア対象のアプリケーションの識別情報が渡されてくるものとする。ここではリストア対象のアプリケーションを「アプリケーションA」と呼ぶ。
ステップS801では、マージ制御部203は、リストア処理の要求を受けると、アプリケーションAのJARファイルのマージ先を特定する。具体的にはアプリ管理テーブルのMergePathの情報を参照して特定する。ここでは仮にアプリケーションBにマージされていたものとする。
ステップS802では、マージ制御部203は、アプリケーションBのJARファイルを退避ファイルから復元する。
ステップS803では、マージ制御部203は、管理テーブルを更新する。具体的には、アプリケーションAのMergeFlagを「False」に設定し、MaxFdUsageを+1した値に設定する。また、MergePathの情報を削除する。また、アプリケーションBのMergeFlagを「False」に設定し、MergePathの情報を削除する。
ステップS804では、マージ制御部203は、他にアプリケーションBにマージしていたアプリケーションを特定する。具体的には、アプリ管理テーブルのMergePathにアプリケーションBのパスが設定されているアプリケーションを特定することで特定を行う。
ステップS805では、マージ制御部203は、S804で特定した情報をもとに他にアプリケーションBにマージしていたアプリケーションが存在するかを判定する。存在すると判定した場合はS806に進み、存在しないと判定した場合は処理を終了する。
ステップS806では、マージ制御部203は、S804で特定した全てのアプリケーションについてアプリケーションBへのマージ処理を行う。マージ処理の詳細は図7を参照して説明した通りである。
以上説明したとおり第1実施形態によれば、フラグメントアプリケーションのJARフィルをホストアプリケーションのJARファイルに結合(マージ)する。これにより、ホストアプリケーションを開始する際にクラスローダが開くファイル数を削減することが出来る。
すなわち、ファイルディスクリプタの使用量を抑えることができるようになるため、従来よりも多くのアプリケーションをインストールして利用することが可能になる。たとえば、対応言語追加用のフラグメントアプリケーションが大量に追加された場合においても開くJARファイルを増加することがなくなる。そのため、他のアプリケーションをより多くインストールして利用可能になりユーザの利便性が向上する。
(第2実施形態)
上述の第1実施形態ではフラグメントアプリケーションをホストアプリケーションにマージする形態であるため、フラグメントアプリケーションが存在しない場合にはファイルディスクリプタを削減することが出来ない。そこで、第2実施形態では、ホストアプリケーション同士であってもマージする形態について説明する。なお、装置の構成(図1〜図4については第1実施形態と同様であるため説明を省略する。また、アプリケーションをインストールする際の処理(図5)以外の処理(図6〜図8)についても第1実施形態と同様であるため説明を省略する。
上述の第1実施形態ではフラグメントアプリケーションをホストアプリケーションにマージする形態であるため、フラグメントアプリケーションが存在しない場合にはファイルディスクリプタを削減することが出来ない。そこで、第2実施形態では、ホストアプリケーション同士であってもマージする形態について説明する。なお、装置の構成(図1〜図4については第1実施形態と同様であるため説明を省略する。また、アプリケーションをインストールする際の処理(図5)以外の処理(図6〜図8)についても第1実施形態と同様であるため説明を省略する。
図9は、アプリケーションをインストールする際の処理を示すフローチャートである。当該処理は、アプリケーションのインストール要求を受信すると実行される。なお、S901〜S910の処理は第1実施形態(図5)のS501〜S510と同様であるため説明を省略する。
ステップS911では、アプリ管理部202は、未マージのホストアプリケーションのうち重複ファイルがないアプリケーションの組が存在するかを判定する。ここで重複ファイルのチェックは、属性定義ファイル以外の構成ファイルに重複がないことを確認することにより行う。構成ファイルに重複のないアプリケーションが存在すると判定した場合はS912に進み、存在しないと判定した場合はS916に進む。
なお、JARファイルの仕様として属性定義ファイルの名前は固定で必ず重複するためこのファイルはチェックから除外する。また、同名で異なるクラスファイルやリソースファイルが存在した状態でマージすると、一方のアプリケーションが想定した処理を行えなくなる。あるいは、中身が同じクラスだとしてもスタティック変数の競合が発生するなどして正常動作しなくなる場合がある。そのため、属性定義ファイル以外に重複がないホストストアプリケーションだけをマージ対象にしている。
ステップS912では、アプリ管理部202は、S911の判定時に特定したホストアプリケーションの製造元(ベンダ)が同一であるかを判定する。同一ベンダでないと判定した場合はS911に進み、同一ベンダであると判定した場合はS913に進む。
ホストアプリケーションのJARファイルをマージするとクラスローダも共通になるため各ホストアプリケーションが保持しているデータに相互にアクセスできるようになってしまう。そのため、セキュリティ上の問題が発生し得る異なるベンダのアプリケーションのマージは行わないようにしている。
ステップS913では、アプリ管理部202は、S911での判定時に特定したアプリケーションの組をマージ対象リストに追加する。
ステップS914では、アプリ管理部202は、マージ対象リストに存在するアプリケーションをマージした際のファイルディスクリプタ使用数を算出する。そして、ファイルディスクリプタ使用数が、画像形成装置で利用可能なファイルディスクリプタ数の上限を超えているか否かを判定する。上限を超えていると判定した場合はS911に進み、上限を超えていないと判定した場合はS915に進む。
ステップS915では、アプリ管理部202は、マージ対象リストに記載されたアプリケーションの識別情報をもとにリストに記載されているすべてのアプリケーションの組に対してマージ処理を行い、処理を終了する。一方、ステップS916では、アプリ管理部202は、S901でインストールしたアプリケーションをアンインストールしてインストールエラーを返し、処理を終了する。
以上説明したとおり第2実施形態によれば、構成ファイルに重複がなくかつ製造元(ベンダ)が同一である場合にはホストアプリケーション同士であってもマージ処理を行う。これにより、第1実施形態に比較し、より多くのファイルディスクリプタを削減できるようになり、より多くのアプリケーションを利用することが可能になる。
(変形例)
上述の実施形態においては、アプリケーションをインストールするタイミングで、アプリケーションのマージ処理を行うよう説明した。しかしながら、マージ処理のタイミングはインストール時に限られるものではなく、ホストアプリケーションの開始指示を受けたタイミングで実施するようにしてもよい。また、アプリケーションをアンインストールするタイミングで、リストア処理を行うよう説明した。しかしながら、リストア処理のタイミングはアンインストール時に限られるものではなく、ホストアプリケーションの停止指示を受けたタイミングで実施するようにしてもよい。
上述の実施形態においては、アプリケーションをインストールするタイミングで、アプリケーションのマージ処理を行うよう説明した。しかしながら、マージ処理のタイミングはインストール時に限られるものではなく、ホストアプリケーションの開始指示を受けたタイミングで実施するようにしてもよい。また、アプリケーションをアンインストールするタイミングで、リストア処理を行うよう説明した。しかしながら、リストア処理のタイミングはアンインストール時に限られるものではなく、ホストアプリケーションの停止指示を受けたタイミングで実施するようにしてもよい。
(その他の実施例)
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。
201 アプリフレームワーク; 202 アプリ管理部; 203 マージ制御部; 208 ホストアプリケーション; 209 フラグメントアプリケーション; 213 アプリクラスローダ
Claims (12)
- 情報処理装置上で動作する複数のアプリケーションを管理する管理装置であって、
アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、
前記判定手段により従属アプリケーションと判定された第1アプリケーションと、前記判定手段により独立アプリケーションと判定されかつ前記第1アプリケーションが紐づく第2アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、
を有することを特徴とする管理装置。 - 前記第1アプリケーションと前記第2アプリケーションとにより使用されるリソースの合計が所定の上限値を超えているか否かを判定するリソース判定手段をさらに有し、
前記構成手段は、前記リソース判定手段により前記合計が前記所定の上限値を超えていると判定された場合に前記結合アプリケーションを構成する
ことを特徴とする請求項1に記載の管理装置。 - 前記第2アプリケーションに紐づく前記第1アプリケーション以外の従属アプリケーションである第3アプリケーションを特定する特定手段をさらに有し、
前記構成手段は、前記第1アプリケーションと前記第2アプリケーションと前記第3アプリケーションとを結合して第2の結合アプリケーションを構成する
ことを特徴とする請求項2に記載の管理装置。 - 前記リソース判定手段は、前記構成手段が前記結合アプリケーションを構成した後、前記結合アプリケーションと前記第3アプリケーションとにより使用されるリソースの第2の合計が前記所定の上限値を超えているか否かを更に判定し、
前記構成手段は、前記リソース判定手段により前記第2の合計が前記所定の上限値を超えていると判定された場合に前記第2の結合アプリケーションを構成する
ことを特徴とする請求項3に記載の管理装置。 - 前記リソースは、ファイルディスクリプタであり、
前記所定の上限値は、前記情報処理装置で使用可能なファイルディスクリプタの上限値である
ことを特徴とする請求項2乃至4の何れか1項に記載の管理装置。 - 前記構成手段が前記結合アプリケーションを構成する場合に、前記第2アプリケーションに含まれるファイルのバックアップを保存する保存手段をさらに有する
ことを特徴とする請求項1乃至5の何れか1項に記載の管理装置。 - アプリケーションが、前記結合アプリケーションであるか否かを判定する結合判定手段と、
アプリケーションを削除する削除手段と、
をさらに有し、
前記削除手段は、前記結合判定手段により前記結合アプリケーションであると判定されたアプリケーションを削除する場合、前記保存手段により保存されたバックアップを利用して前記第2アプリケーションを復元する
ことを特徴とする請求項6に記載の管理装置。 - アプリケーションをインストールするインストール手段をさらに有し、
前記構成手段は、前記インストール手段が前記第1アプリケーションと前記第2アプリケーションとをインストールするタイミングで前記結合アプリケーションを構成し、前記インストール手段は、前記結合アプリケーションをインストールする
ことを特徴とする請求項1乃至7の何れか1項に記載の管理装置。 - 前記複数のアプリケーションの各々は属性定義ファイルを含み、
前記インストール手段は、インストール対象のアプリケーションの属性定義ファイルに基づいて管理テーブルを生成する
ことを特徴とする請求項8に記載の管理装置。 - 前記構成手段は、第1の独立アプリケーションと第2の独立アプリケーションとに関して含まれるファイルに重複がなくかつ製造元が同一である場合、前記第1の独立アプリケーションと前記第2の独立アプリケーションとを結合して結合アプリケーションを構成する
ことを特徴とする請求項1乃至9の何れか1項に記載の管理装置。 - 情報処理装置上で動作する複数のアプリケーションを管理する管理装置の制御方法であって、
アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定工程と、
前記判定工程により従属アプリケーションと判定された第1アプリケーションと、前記判定工程により独立アプリケーションと判定されかつ前記第1アプリケーションが紐づく第2アプリケーションと、を結合して結合アプリケーションを構成する構成工程と、
を含むことを特徴とする制御方法。 - 請求項11に記載の制御方法をコンピュータに実行させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020090827A JP2021189487A (ja) | 2020-05-25 | 2020-05-25 | 管理装置およびその制御方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020090827A JP2021189487A (ja) | 2020-05-25 | 2020-05-25 | 管理装置およびその制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2021189487A true JP2021189487A (ja) | 2021-12-13 |
Family
ID=78849487
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020090827A Pending JP2021189487A (ja) | 2020-05-25 | 2020-05-25 | 管理装置およびその制御方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2021189487A (ja) |
-
2020
- 2020-05-25 JP JP2020090827A patent/JP2021189487A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5294892B2 (ja) | 画像形成装置、装置、制御方法、及びプログラム | |
US8854651B2 (en) | Image forming apparatus, information processing method, and recording medium indicating a version of a function supported by the image forming apparatus | |
JP2008084304A (ja) | 画像形成装置、プログラム更新方法及びプログラム | |
US10558405B2 (en) | Information processing apparatus and driver customizing method | |
JP2014170515A (ja) | 機器、情報記録プログラム、及び情報記録方法 | |
US10089102B2 (en) | Information processing apparatus, method, and program | |
JP2019101866A (ja) | アプリケーションの更新方法およびプログラム | |
US11140291B2 (en) | Information processing apparatus, control method thereof, and storage medium | |
JP2008084029A (ja) | 仮想マシン管理システム | |
US9086938B2 (en) | Information processing apparatus, control method thereof, and storage medium | |
JP4946141B2 (ja) | 構成変更プログラム、および情報処理装置 | |
CN109660688B (zh) | 信息处理装置及其控制方法 | |
JP2011242891A (ja) | 配信装置、画像処理装置、配信方法及びインストール方法 | |
JP2008059238A (ja) | 通信システム及びそれに使用するプリンタ | |
US10545704B2 (en) | Image forming apparatus and control method to update an application in an image forming apparatus | |
US9742948B2 (en) | Image forming apparatus and method for deleting application | |
JP2009163760A (ja) | 情報処理装置とその方法及びプログラム | |
JP6866788B2 (ja) | 情報処理装置及びプログラム | |
US9940334B2 (en) | Image forming apparatus and control method thereof | |
JP2021189487A (ja) | 管理装置およびその制御方法 | |
US9753775B2 (en) | Resource management apparatus and resource management method | |
US10554841B2 (en) | Image forming apparatus, control method thereof and medium | |
KR101845467B1 (ko) | 빠른 부팅을 위한 부트 이미지의 에러를 복구하는 방법 및 이를 수행하는 화상형성장치 | |
US20200311253A1 (en) | Information processing apparatus, control method for information processing apparatus, and storage medium | |
US20220261472A1 (en) | Information processing apparatus, method, and program storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20210103 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210113 |