harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [classlib]Make harmony's modularity better
Date Thu, 18 Dec 2008 11:52:35 GMT
I've been looking at the dependency from the auth module to awt, but I
don't think there's any work to be done there, except to change the
awt dependencies in the MANIFEST.MF to be optional.
There is only one class that depends on awt
(org.apache.harmony.auth.callback.DialogCallbackHandler), and I
believe for it to be instantiated a user would have to specify its
name via the auth.login.defaultCallbackHandler security property.  If
that's right, then I think we could just assume that that won't/can't
be used if awt isn't installed.
I don't think it makes sense to move the class itself to awt as that
would introduce a dependency from awt-auth that doesn't already exist.

Does that sound ok?



2008/12/18 Tim Ellison <t.p.ellison@gmail.com>:
> Jack,  do we have an ACQ for your contributions to Harmony?
> I couldn't see one in the files, but might have missed it.
> If you have not sent us one before, please complete the form [1] and
> send a scanned copy to private@harmony.apache.org
> [1] http://harmony.apache.org/auth_cont_quest.html
> Thanks,
> Tim
> Jack Cai wrote:
>> I have another try following Alex's idea. See the patch here [1].
>> -Jack
>> [1]
>> https://issues.apache.org/jira/secure/attachment/12396303/HARMONY-6050_Jack.diff
>> 2008/12/17 Tim Ellison <t.p.ellison@gmail.com>
>>> Alex Blewitt wrote:
>>>>> But the solution would be to do:
>>>>> Beans. instantiate/2 -> Beans. instantiate/3
>>>>> Beans. instantiate/3 (does the work)
>>>>> Beans. instantiate/4 -> Beans. instantiate/3 (and calls the applet
>>> initialiser)
>>>> I've attached such a proposed change to
>>>> https://issues.apache.org/jira/browse/HARMONY-6050. Sorry I can't
>>>> compile/test in-situ, but if someone can give that a go and run
>>>> associated tests, that would be great.
>>> I took another look, and it isn't so simple.  While we know the caller
>>> to the instantiate/4 method has got applet loaded, we also have to deal
>>> with the case where instantiate/3 loads a bean of type Applet.
>>> We should not inadvertently load applet.jar by deferring /3 to /4, but
>>> we still need to cope with potentially loading it for the /3 case.  If
>>> you are still following me...
>>> Regards,
>>> Tim

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message