You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/11/07 08:28:57 UTC
ExcaliburComponentManagerServlet
Hi,
Could someone look at ExcaliburComponentManagerServlet. Has it ever been
released? If no one objects, can I change the exporting of the
ComponentManager into the Context into exporting of ServiceManager?
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManagerServlet
Posted by Peter Donald <pe...@apache.org>.
On Fri, 8 Nov 2002 05:33, Leif Mortenson wrote:
> Peter Donald wrote:
> > However long term I would prefer that it get moved into ECM and
> > fortress implement a proper Proxy management (which included proxying
> > objects prior to them being made available via the SM or CM).
done.
> I'll look at it again when I get some more energy. I just spent way too
> many hours learning the
> quirks of the objects returned by java.lang.reflect.Proxy. It turns
> out that their equals method
> always returns false. So you could have a proxy p and execute p.equals(
> p ) and get false.
ick !
> Anyway, if some more people could pound on it that would be great.
--
Cheers,
Peter Donald
"Man's mind stretched to a new idea never goes back to its original
dimensions." -Oliver Wendell Holmes
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManagerServlet
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Peter Donald wrote:
>>What would you think about moving the ComponentProxyGenerator over as
>>well. Doing so would
>>remove the need for the Container package by the Component package (?)
>>Seems to make
>>as much sense as moving the WrapperServiceManager class.
>>
>>
>
>I am not sure I like it. The main reason is that there is no consensus on how
>proxys are generated. ie In Phoenix/Merlin the lookup key will not
>necessarily match the interface name and thus the proxy would never work in
>this situation. In ECM/Fortress it works by virtue of
>
>key == role + decoration
>
>I would feel more comfortable if the code was moved either into both ECM and
>fortress (It would reduce coupling and thus IMHO the duplication is not bad).
>However long term I would prefer that it get moved into ECM and fortress
>implement a proper Proxy management (which included proxying objects prior to
>them being made available via the SM or CM).
>
I'll look at it again when I get some more energy. I just spent way too
many hours learning the
quirks of the objects returned by java.lang.reflect.Proxy. It turns
out that their equals method
always returns false. So you could have a proxy p and execute p.equals(
p ) and get false.
Several places in the code were using collections classes which do not
test for object equality
so this was leading to all kinds of problems trying to decommission
components which did not
implement the Component interface.
Anyway, it is all fixed now.
The ECM now supports the use of components which do not implement
Component. This
"feature" had been in there for a while, but it did not appear to work
correctly in several cases.
It ran into problems when a component implemented Serviceable but not
Component, for
example.
Anyway, if some more people could pound on it that would be great.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManagerServlet
Posted by Peter Donald <pe...@apache.org>.
On Thu, 7 Nov 2002 22:42, Leif Mortenson wrote:
> Stuff started breaking again because you moved the
> ComponentManager2ServiceManager
> over to Framework as the WrapperServiceManager.
>
> That is fixed now. No problem.
ops. Results from me not using Selectors ;)
> What would you think about moving the ComponentProxyGenerator over as
> well. Doing so would
> remove the need for the Container package by the Component package (?)
> Seems to make
> as much sense as moving the WrapperServiceManager class.
I am not sure I like it. The main reason is that there is no consensus on how
proxys are generated. ie In Phoenix/Merlin the lookup key will not
necessarily match the interface name and thus the proxy would never work in
this situation. In ECM/Fortress it works by virtue of
key == role + decoration
I would feel more comfortable if the code was moved either into both ECM and
fortress (It would reduce coupling and thus IMHO the duplication is not bad).
However long term I would prefer that it get moved into ECM and fortress
implement a proper Proxy management (which included proxying objects prior to
them being made available via the SM or CM).
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManagerServlet
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Stuff started breaking again because you moved the
ComponentManager2ServiceManager
over to Framework as the WrapperServiceManager.
That is fixed now. No problem.
What would you think about moving the ComponentProxyGenerator over as
well. Doing so would
remove the need for the Container package by the Component package (?)
Seems to make
as much sense as moving the WrapperServiceManager class.
Cheers,
Leif
Leif Mortenson wrote:
> Peter Donald wrote:
>
>> Hi,
>>
>> Could someone look at ExcaliburComponentManagerServlet. Has it ever
>> been released? If no one objects, can I change the exporting of the
>> ComponentManager into the Context into exporting of ServiceManager?
>>
> Good idea. I went ahead and modified the
> ExcaliburComponentManagerCreator and
> and ExcaliburComponentManagerServlet to provide access to a
> ServiceManager
> object. The ComponentManager is still available, but it is now
> deprecated.
>
> I also added a new AbstractServiceManagerServlet class and deprecated the
> AbstractComponentManagerServlet class. These classes can be used to
> easily write
> servlets which have immediate access to a Com.. (ahem) ServiceManager,
> LoggerManager and InstrumentManager. They are also instrumented by
> default, making
> it easy to do performance tests of servlets.
>
> Take a look at my changes and let me know if you have any additional
> changes you
> would like.
>
>
> Cheers,
> Leif
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManagerServlet
Posted by Peter Donald <pe...@apache.org>.
On Thu, 7 Nov 2002 20:51, Leif Mortenson wrote:
> Take a look at my changes and let me know if you have any additional
> changes you
> would like.
works for me
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExcaliburComponentManagerServlet
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Peter Donald wrote:
>Hi,
>
>Could someone look at ExcaliburComponentManagerServlet. Has it ever been
>released? If no one objects, can I change the exporting of the
>ComponentManager into the Context into exporting of ServiceManager?
>
Good idea. I went ahead and modified the
ExcaliburComponentManagerCreator and
and ExcaliburComponentManagerServlet to provide access to a ServiceManager
object. The ComponentManager is still available, but it is now deprecated.
I also added a new AbstractServiceManagerServlet class and deprecated the
AbstractComponentManagerServlet class. These classes can be used to
easily write
servlets which have immediate access to a Com.. (ahem) ServiceManager,
LoggerManager and InstrumentManager. They are also instrumented by
default, making
it easy to do performance tests of servlets.
Take a look at my changes and let me know if you have any additional
changes you
would like.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>