[proxy] sfl4j-like discovery for ProxyFactory...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[proxy] sfl4j-like discovery for ProxyFactory...

James Carman
All,

The wicket folks are investigating using Commons Proxy and they don't
want to have to decide which implementation (jdk, cglib, javassist) to
use themselves.  They would like us to split up Commons Proxy into 3
jars, commons-proxy, commons-proxy-cglib, commons-proxy-javassist.
Any thoughts?

James

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proxy] sfl4j-like discovery for ProxyFactory...

Torsten Curdt

On 08.03.2008, at 13:44, James Carman wrote:

> All,
>
> The wicket folks are investigating using Commons Proxy and they don't
> want to have to decide which implementation (jdk, cglib, javassist) to
> use themselves.  They would like us to split up Commons Proxy into 3
> jars, commons-proxy, commons-proxy-cglib, commons-proxy-javassist.
> Any thoughts?

Is the discovery such a big problem with proxy? ...in general I  
prefer the static discovery type. But someone has to do it.

My 2 cents

cheers
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proxy] sfl4j-like discovery for ProxyFactory...

James Carman
On 3/8/08, Torsten Curdt <[hidden email]> wrote:

>
>  On 08.03.2008, at 13:44, James Carman wrote:
>
>  > All,
>  >
>  > The wicket folks are investigating using Commons Proxy and they don't
>  > want to have to decide which implementation (jdk, cglib, javassist) to
>  > use themselves.  They would like us to split up Commons Proxy into 3
>  > jars, commons-proxy, commons-proxy-cglib, commons-proxy-javassist.
>  > Any thoughts?
>
>
> Is the discovery such a big problem with proxy? ...in general I
>  prefer the static discovery type. But someone has to do it.

Well, Johan makes a good case.  He's writing some code that he wants
to use Proxy, but he doesn't want to have to figure out what
implementation to use himself.  He'd rather it be done automatically
for him, by doing something like ProxyFactory.getInstance().  I
thought about this at one time.  I guess we could say, instantiate
your class that's based on Proxy by passing in whatever implementation
the client wants.  So, he could have something like:

public class MyFrameworkClass
{
  public MyFrameworkClass(ProxyFactory proxyFactory)
  {
    this.proxyFactory = proxyFactory;
  }

  public Object createSomeKindOfProxy(SomeArgument arg)
  {
    return proxyFactory.create...
  }
}

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proxy] sfl4j-like discovery for ProxyFactory...

Torsten Curdt

On 08.03.2008, at 15:25, James Carman wrote:

> On 3/8/08, Torsten Curdt <[hidden email]> wrote:
>>
>>  On 08.03.2008, at 13:44, James Carman wrote:
>>
>>> All,
>>>
>>> The wicket folks are investigating using Commons Proxy and they  
>>> don't
>>> want to have to decide which implementation (jdk, cglib,  
>>> javassist) to
>>> use themselves.  They would like us to split up Commons Proxy into 3
>>> jars, commons-proxy, commons-proxy-cglib, commons-proxy-javassist.
>>> Any thoughts?
>>
>>
>> Is the discovery such a big problem with proxy? ...in general I
>>  prefer the static discovery type. But someone has to do it.
>
> Well, Johan makes a good case.  He's writing some code that he wants
> to use Proxy, but he doesn't want to have to figure out what
> implementation to use himself.  He'd rather it be done automatically
> for him, by doing something like ProxyFactory.getInstance().  I
> thought about this at one time.  I guess we could say, instantiate
> your class that's based on Proxy by passing in whatever implementation
> the client wants.  So, he could have something like:
>
> public class MyFrameworkClass
> {
>   public MyFrameworkClass(ProxyFactory proxyFactory)
>   {
>     this.proxyFactory = proxyFactory;
>   }
>
>   public Object createSomeKindOfProxy(SomeArgument arg)
>   {
>     return proxyFactory.create...
>   }
> }

Well, one could just try and see what classes are available in the  
classpath. This could be easily be done in a wrapper class as you  
suggested.

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [proxy] sfl4j-like discovery for ProxyFactory...

James Carman
On 3/8/08, Torsten Curdt <[hidden email]> wrote:
> Well, one could just try and see what classes are available in the
>  classpath. This could be easily be done in a wrapper class as you
>  suggested.

So, what do you think we should do about PROXY-11?

http://issues.apache.org/jira/browse/PROXY-11

>
>
>  cheers
>  --
>  Torsten
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [proxy] sfl4j-like discovery for ProxyFactory...

Jörg Schaible-2
In reply to this post by Torsten Curdt
Torsten Curdt wrote:

> On 08.03.2008, at 15:25, James Carman wrote:
>
>> On 3/8/08, Torsten Curdt <[hidden email]> wrote:
>>>
>>>  On 08.03.2008, at 13:44, James Carman wrote:
>>>
>>>> All,
>>>>
>>>> The wicket folks are investigating using Commons Proxy and they
>>>> don't want to have to decide which implementation (jdk, cglib,
>>>> javassist) to use themselves.  They would like us to split up
>>>> Commons Proxy into 3 jars, commons-proxy, commons-proxy-cglib,
>>>> commons-proxy-javassist. Any thoughts?
>>>
>>>
>>> Is the discovery such a big problem with proxy? ...in general I
>>>  prefer the static discovery type. But someone has to do it.
>>
>> Well, Johan makes a good case.  He's writing some code that he wants
>> to use Proxy, but he doesn't want to have to figure out what
>> implementation to use himself.  He'd rather it be done automatically
>> for him, by doing something like ProxyFactory.getInstance().  I
>> thought about this at one time.  I guess we could say, instantiate
>> your class that's based on Proxy by passing in whatever
>> implementation the client wants.  So, he could have something like:
>>
>> public class MyFrameworkClass
>> {
>>   public MyFrameworkClass(ProxyFactory proxyFactory)   {
>>     this.proxyFactory = proxyFactory;
>>   }
>>
>>   public Object createSomeKindOfProxy(SomeArgument arg)   {
>>     return proxyFactory.create...
>>   }
>> }
>
> Well, one could just try and see what classes are available in the
> classpath. This could be easily be done in a wrapper class as you
> suggested.

Shrug. And suddenly someone adds a new library that introduces new deps (e.g. Hibernate to CGLIB). Why not simply use JDK proxy as default and use a system property to override the default selection? If a project is dependend on a more powerful proxy implementation they have to select one themselves or document this fact for their users (e.g. they have to use CGLIB- or JavaAssist-based proxies).

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]