Short-term, this fix seems ok. Long-term, would it make sense to
separate this class into a server and client version? Having a harder
line of separation would help prevent similar issues in the future.
- Keith
On 02/15/11 03:09 PM, John Fischer wrote:
All,
Let's try that again.
The webrev is located at:
http://cr.opensolaris.org/~johnfisc/7019724-aimdns/
Thanks Mary and Drew for jumping on that quickly.
John
On 02/15/11 03:02 PM, John Fischer wrote:
All,
Here is a webrev for CR 7019724:
http://monaco.sfbay.sun.com/detail.jsf?cr=7019724
The webrev is located at:
http://monaco.sfbay.sun.com/detail.jsf?cr=7019724
During tests of the webserver project the clients contained the
installadm package and thus had access to the install/server SMF
service information. So what happened is when the webserver package
bug (CR 7018370) removed a dependency on installadm the
client no longer had access to the install/server SMF service
information.
This meant that the client would try to get the all_services properties
and fail. Thus the install would stop. However, the client does not
need to have those properties. So the solution is to move the
initialization
of the properties into the register portion of the code which is done on
the server side of the house that has access to the appropriate
install/server SMF service information.
Thanks,
John
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
