| ID |
Location in the spec (use links if possible) |
Comments/Discussion |
Resolved – (YES/NO) |
|
KM001 |
Overall |
Good document! |
Yes |
|
KM002 |
2.1 Installation |
You have said that by default all the applications residing in lib/install/applications are considered of type "system-all" and will be deployed in all instances. Comment: I don't think this is accurate. The applications residing here (usually in expanded format) are not necessarily deployed to all the instances. Examples are adminapp and admingui which are only deployed to DAS. |
|
|
KM003 |
2.1 Installation |
I have some reservations against taking an approach where the addon bits are independently installed on all the machines of interest. There are various not-so-good implications of this. Examples: 1. The addon has to be an install time decision rather than an administration decision. The addon is run by the app server runtime, but it is installed a priori. 2. Installer screens are rendered complicated and we might end up asking various questions. 3. It has to be done on every node agent machine! |
|
|
KM004 |
2.1 Installation |
Can we consider an addon as a lifecycle module that can leverage the synchronization support at the DAS level? That will completely remove the installation overhead. |
|
|
KM005 |
2.2.2 |
I don't understand this section. Can you please elaborate? For example, what System Properties are you referring to? |
|
|
KM006 |
Overall |
It appears to me that you have chosen a silent configuration of addons on clusters and instances. How will this work for a generic addon? I believe that addon enablement on a particular target (cluster, instance) has got to be administrator activity for a given domain. If we consider it this way, we don't even need the distinction like "system" or "user" on lifecycle modules. I have also elaborated this at length in a private e-mail to you. |
|
|
KM007 |
3.1 |
What is the real interface – DOMAIN_DIR/config/addon.properties or DOMAIN_DIR/config/domain-registry? I have been seeing this domain-registry file getting created. |
|
|
KM008 |
3.1 |
You say: "The configurator plugin of the addon is expected to rollback the changes it made during the configuration." Comment: I am not sure how. Can you please explain? Isn't it tricky? What if same set of settings is shared by multiple addons? Also, are you mandating that addon configurators remember/persist the settings they once did? I did not see that being specified anywhere. |
|
|
KM009 |
3.2 |
Uninstallation of SDK? – Does it mean this is an SDK specific addon? Can pure app server bits (as in Solaris or stand-alone installer) not leverage this framework? Also, isn't the installation folder going to get wiped out anyway? |
|
|
KM010 |
Overall |
Please fix typos. |
|
|
KM011 |
Javadoc (Please provide an external link to them) |
I don't understand the provision of AddonException and AddonFatalException. Can't one suffice? In general, why should an addon installation failure result in app server installation failure? |
|
|
KM012 |
Javadoc (Please provide an external link to them) |
AddonFatalException is an AddonException. Why? I see no inheritance between the two. |
|
|
KM013 |
Javadoc (Please provide an external link to them) |
ConfigurationContext – I don't understand the purpose of instance-directory and domain-directory here. Where did you mention it in the one pager? |
|
|
KM014 |
Javadoc (Please provide an external link to them) |
What is ConfigurationContext.ConfigurationType for? |
|
