Carsten Ziegeler wrote:
> Thanks for clarification, Berin! Inline are some comments:
>
> Berin Loritsch wrote:
>>The biggest thing you will have to do to migrate to Fortress is to
>>change your cocoon.roles file format. It is the roles file that now
>>determines the "lifestyle" of a component, and the marker interfaces
>>SingleThreaded, ThreadSafe, and Poolable do not have any meaning any
>>more.
>>
>
> Argh...sorry, I don't want to question this, but I simply do not like
> it. What will happen if I write a "SingleThreaded" implementation and
> configure it as ThreadSafe...
Then it will act as ThreadSafe. What this change does is #1 prepares
you for the shift to true meta information (as close to attribute
driven development as Java will get), and #2 prevents any conflict
as to Lifestyle.
What happens if you have an abstract implementation of a component
that implements Poolable, but a concrete implementation that implements
ThreadSafe (more true to life)? That is an error, and it will cause
any container respecting those interfaces to reject your interface.
Now you have to look down the inheritance heirarchy to figure out what
to do about it! That is just bad. At least by configuring the
lifestyle in a separate file, you are not subject to any of the Java
class inheritance rules.
>>Your Poolable components would have to change because Fortress uses
>>the MPool package (part of the Event package). The Poolable and
>>Resettable interfaces are not there. I do need to provide a mechanism
>>for the MPool package so that we can reset components.
>
> Do you mean Resettable or Recyclable?
Recyclable--I was going by memory, and I haven't used the Pool package
in a while.
>>My question for you guys is whether you want me to force you to change
>>your interface for Resettable, or to have MPool work by reflection and
>>discover if there is a reset() method with public access. If that is
>>the case, then MPool would be able to call it--whether there was an
>>interface or not. I think the latter would be preferable, as it is
>>much more flexible--I just need to make it explicit that is what is
>>happening.
>>
>
>
> We need a way to invoke the recycle() method in the current implementations,
> so a support for Recyclable is required.
:) I can do that without requiring that interface! I will use the
reflection facilities to determine if there is a "recycle()" method
with public access, and then call it. I will probably get that done
within the next couple of days.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
