At 08:45 AM 6/11/2002 +0200, you wrote:
>>>>2) removal of release()
>
>-1
>
>Still don't understand how I can deallocate a scarse resource as soon
>as possible :-/
>How the hell can I release a scarse resource right away?
Same way as you deal with all resources. ie call close(), release() etc.
The Connector API aims to standardize heavy resource management in J2EE
land and JDBC will implement it in the future (unless JDK1.4 version does?)
and most vendors will use that API.
For lower cost in memory objects then you release them or put them back in
the pool explicitly ala
interface GeneratorManager
{
get()
release()
}
>>>>3) replacement of Component with Object
>>>
>>>+1s
>
>+1
>
>Why did we use _Component_ in the first place?
Because I couldn't think of a good reason to kill it in the first place ;)
>that the container could recognize an Avalon Component ad treat it as such.
No. Thats why we had the Block/Service interfaces (in Phoenix). As a sort
of metainfo to identify objects but that ended up being a bad idea as we
had metainfo scattered across configuration files and implemenentation
classes. The motivation for Component was different.
>What was the need?
Mainly as it forces people to think about what constitutes a service and
what isn't. ie It clearly markes the difference between Component and
Object. In effect it did not really achieve that end. If you look at some
of the code I wrote I ended up having to do a lot of work arounds. Consider
the case where I have service X that is independent of Avalon. To use it I
ended up having to having to do
class ExtendedX extends A implements Component
{
}
or
interface XManager
{
X getX();
}
Neither which are elegant. You can still see the remanents of this sort of
thing in things like PhoenixPackageManager.
>>>>5) addition of an _optional_ lookup() method that supports hints, to
>>>>enable smooth migration from ComponentSelector usage
>>>
>>>-1s
>> From a pure framework perspective I'm totally in agreement with the
>> above (irrespective of the pain and suffering I'm enduring with respect
>> to the metainfo/metadata issues inflicted by an unmentionable
>> "Australia" personality). However, if we take into account ECM and the
>> interest in facilitating a smooth migration path, I see only two
>> alternative; either we provide a lookup( role, hint) in the framework
>> (which I dislike in terms of the curent form being dicusssed), or (b) an
>> extended CM is defintion at the excalibur level that provide a bridge
>> from ECM to the emerging container models.
>
>Now, this thing of /hints/ got me thinking.
>
>As I said previously, it seems that:
>
>Role: what
>Hint: how
>
>This means that if I ask for an XSLT processor, I can hint to use Saxon,
>but it can give me also Crimson.
>No problem for me, as long as it's XSLT spec compatible (ROLE).
This is very very similar to what Stephen is doing in Merlin wrt to
policies. ie Component A declares a dependency on Role P. If there is only
one P in the system then that P will be used - however if there is multiple
Ps in the system (namely x, y and z) then one of them will be selected
based on a heuristic that takes a policy (aka a hint).
The difference between Merlins model and the Cocoon model is that in Cocoon
the metainfo (ie hint) is stored in code while in Merlin it is stored in
descriptor (aka a .xinfo file).
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
