You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by James Carman <ja...@carmanconsulting.com> on 2006/05/12 21:51:35 UTC
HiveMind 2.0
All,
In HiveMind 2.0, it'd be nice to change some of the API around a bit. For
instance:
1. The registry implementation should be handed a ProxyFactory (like the
one from Jakarta Commons Proxy) in the constructor which allows us to
substitute proxying techniques. Jakarta Commons Proxy already has code for
this and we should either copy it or use it as a dependency. This would
abstract away all of the proxying logic from our (and users) code.
2. The interceptor factories shouldn't be given access to the "interceptor
stack." They should just have to return an interceptor instance (we could
create our own interceptor interface or use AOP Alliance's API). HiveMind
itself will take care of putting the interceptor onto the stack by creating
an intercepting proxy using the ProxyFactory. After all, don't you find it
weird that a "factory" doesn't really return anything? This is a really big
one, IMHO. The Javassist stuff is just too difficult for the everyday user.
But, they can instantiate an interceptor object quite easily.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: HiveMind 2.0
Posted by James Carman <ja...@carmanconsulting.com>.
Well, that's one down! :-)
-----Original Message-----
From: Brian K. Wallace [mailto:brian@transmorphix.com]
Sent: Tuesday, May 16, 2006 4:24 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: HiveMind 2.0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Carman wrote:
> Well, JCP doesn't have proxies that "replace" themselves. It can generate
> "delegator" proxies that are place-holders. But, subsequent invocations
> will still have to pass through the proxy in order to delegate to the
actual
> object. The construction of the object can take place at a later time,
> though. If we really need these proxy types, I'll can see what I can do
in
> JCP.
>
> No, I don't have a release yet. I'm preparing for one. Right now, it's
in
> the commons sandbox (so I can't release), but I don't think I'll get too
> much grief if I want to promote it to the "commons proper" (especially if
> something like HiveMind wants to use it).
>
I may only be "one", but since your original proposal to move it out
I've been looking at it and would definitely support its promotion.
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEajTiaCoPKRow/gARAsDRAKCKM4/MOtBeLukdJiSPCoQCPzm7NACfeaEm
GW9TFYXg2nLHJBIvN3hj2co=
=pseZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 2.0
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Carman wrote:
> Well, JCP doesn't have proxies that "replace" themselves. It can generate
> "delegator" proxies that are place-holders. But, subsequent invocations
> will still have to pass through the proxy in order to delegate to the actual
> object. The construction of the object can take place at a later time,
> though. If we really need these proxy types, I'll can see what I can do in
> JCP.
>
> No, I don't have a release yet. I'm preparing for one. Right now, it's in
> the commons sandbox (so I can't release), but I don't think I'll get too
> much grief if I want to promote it to the "commons proper" (especially if
> something like HiveMind wants to use it).
>
I may only be "one", but since your original proposal to move it out
I've been looking at it and would definitely support its promotion.
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEajTiaCoPKRow/gARAsDRAKCKM4/MOtBeLukdJiSPCoQCPzm7NACfeaEm
GW9TFYXg2nLHJBIvN3hj2co=
=pseZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: HiveMind 2.0
Posted by James Carman <ja...@carmanconsulting.com>.
Well, JCP doesn't have proxies that "replace" themselves. It can generate
"delegator" proxies that are place-holders. But, subsequent invocations
will still have to pass through the proxy in order to delegate to the actual
object. The construction of the object can take place at a later time,
though. If we really need these proxy types, I'll can see what I can do in
JCP.
No, I don't have a release yet. I'm preparing for one. Right now, it's in
the commons sandbox (so I can't release), but I don't think I'll get too
much grief if I want to promote it to the "commons proper" (especially if
something like HiveMind wants to use it).
-----Original Message-----
From: Achim Hügen [mailto:achim.huegen@gmx.de]
Sent: Tuesday, May 16, 2006 4:04 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: HiveMind 2.0
Jakarta commons proxy looks good and I would appreciate to reuse a library.
We'll get another dependency but loosen the dependency on javassist and
cglib.
Can we substitute all the advanced proxy stuff that hivemind uses today?
Like inner/outer proxies that replace themselves?
There is no binary release today isn't it? When could we expect one?
Achim
Am Fri, 12 May 2006 21:51:35 +0200 schrieb James Carman
<ja...@carmanconsulting.com>:
> All,
>
> In HiveMind 2.0, it'd be nice to change some of the API around a bit.
> For
> instance:
>
> 1. The registry implementation should be handed a ProxyFactory (like the
> one from Jakarta Commons Proxy) in the constructor which allows us to
> substitute proxying techniques. Jakarta Commons Proxy already has code
> for
> this and we should either copy it or use it as a dependency. This would
> abstract away all of the proxying logic from our (and users) code.
>
> 2. The interceptor factories shouldn't be given access to the
> "interceptor
> stack." They should just have to return an interceptor instance (we
> could
> create our own interceptor interface or use AOP Alliance's API).
> HiveMind
> itself will take care of putting the interceptor onto the stack by
> creating
> an intercepting proxy using the ProxyFactory. After all, don't you find
> it
> weird that a "factory" doesn't really return anything? This is a really
> big
> one, IMHO. The Javassist stuff is just too difficult for the everyday
> user.
> But, they can instantiate an interceptor object quite easily.
>
> Thoughts?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: HiveMind 2.0
Posted by Achim Hügen <ac...@gmx.de>.
Jakarta commons proxy looks good and I would appreciate to reuse a library.
We'll get another dependency but loosen the dependency on javassist and
cglib.
Can we substitute all the advanced proxy stuff that hivemind uses today?
Like inner/outer proxies that replace themselves?
There is no binary release today isn't it? When could we expect one?
Achim
Am Fri, 12 May 2006 21:51:35 +0200 schrieb James Carman
<ja...@carmanconsulting.com>:
> All,
>
> In HiveMind 2.0, it'd be nice to change some of the API around a bit.
> For
> instance:
>
> 1. The registry implementation should be handed a ProxyFactory (like the
> one from Jakarta Commons Proxy) in the constructor which allows us to
> substitute proxying techniques. Jakarta Commons Proxy already has code
> for
> this and we should either copy it or use it as a dependency. This would
> abstract away all of the proxying logic from our (and users) code.
>
> 2. The interceptor factories shouldn't be given access to the
> "interceptor
> stack." They should just have to return an interceptor instance (we
> could
> create our own interceptor interface or use AOP Alliance's API).
> HiveMind
> itself will take care of putting the interceptor onto the stack by
> creating
> an intercepting proxy using the ProxyFactory. After all, don't you find
> it
> weird that a "factory" doesn't really return anything? This is a really
> big
> one, IMHO. The Javassist stuff is just too difficult for the everyday
> user.
> But, they can instantiate an interceptor object quite easily.
>
> Thoughts?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org