On Jul 17, 2010, at 8:07 AM, James Carman wrote:
I've toyed (pardon the pun) with the idea of being more builderish
with
proxy, but not necessarily with the main API.
+1. I had a deeper look at how ProxyToys does its ToyFactories and I
like the fact that [proxy] has a lower-level API; th
I've toyed (pardon the pun) with the idea of being more builderish with
proxy, but not necessarily with the main API. I have ideas for introducing
some of the proxying "patterns" (dare I say, they might ask me to write a
book) from HiveMind, such as pipeline and whatever the other one was that
pic
Matt Benson wrote:
>
> On Jul 16, 2010, at 5:40 PM, Jörg Schaible wrote:
>
>> James Carman wrote:
>>
>>> On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson
>>> wrote:
But you can agree that making the first class a separate argument
preserves the usability of varargs while accomplish
On Sat, Jul 17, 2010 at 12:00 AM, Matt Benson wrote:
> Not sure why one of our own never mentioned the existence of ProxyToys, but
> go figure. ;) I hate to exhibit NIH, but since I jumped into [proxy]
> partly to find a home for my fluent stubbed proxy code, I guess I'll
> persevere here.
>
Pr
On Jul 16, 2010, at 5:40 PM, Jörg Schaible wrote:
James Carman wrote:
On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson
wrote:
But you can agree that making the first class a separate argument
preserves the usability of varargs while accomplishing the typed
result
in a single method?
Mos
We could perhaps set ourselves up for success in many situations. I
like the idea of using ServiceLoader which is part of the JDK. All
that means is that we include a file called
META-INF/services/org.apache.commons.proxy.ProxyFactory and in it we
have the implementation class name. Very low imp
On Jul 16, 2010, at 5:02 PM, James Carman wrote:
> One of the other major requests I've had from folks is the
> "auto-discovery" mechanism. So, basically they just call one static
> method somewhere to obtain a ProxyFactory and based on what's on the
> classpath, we determine what they're talkin
On Jul 16, 2010, at 5:40 PM, Jörg Schaible wrote:
> James Carman wrote:
>
>> On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson wrote:
>>>
>>> But you can agree that making the first class a separate argument
>>> preserves the usability of varargs while accomplishing the typed result
>>> in a single
On Jul 16, 2010, at 4:58 PM, James Carman wrote:
> On Fri, Jul 16, 2010 at 5:48 PM, Matt Benson wrote:
>> Consider it done, then. :)
>>
>> Poor birds.
>>
>
> Sorry, my wife has that "angry birds" application on her ipod touch,
> so I've been on a bird killing spree for the past few weeks.
>
James Carman wrote:
> On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson wrote:
>>
>> But you can agree that making the first class a separate argument
>> preserves the usability of varargs while accomplishing the typed result
>> in a single method?
>>
>
> Most definitely! I like that idea. I would
One of the other major requests I've had from folks is the
"auto-discovery" mechanism. So, basically they just call one static
method somewhere to obtain a ProxyFactory and based on what's on the
classpath, we determine what they're talking about. Perhaps we can
just add that into ProxyUtils? We
On Fri, Jul 16, 2010 at 5:48 PM, Matt Benson wrote:
> Consider it done, then. :)
>
> Poor birds.
>
Sorry, my wife has that "angry birds" application on her ipod touch,
so I've been on a bird killing spree for the past few weeks.
--
On Jul 16, 2010, at 4:43 PM, James Carman wrote:
> On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson wrote:
>>
>> But you can agree that making the first class a separate argument preserves
>> the usability of varargs while accomplishing the typed result in a single
>> method?
>>
>
> Most defini
On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson wrote:
>
> But you can agree that making the first class a separate argument preserves
> the usability of varargs while accomplishing the typed result in a single
> method?
>
Most definitely! I like that idea. I would think that would be the
best w
On Jul 16, 2010, at 3:56 PM, James Carman wrote:
> On Fri, Jul 16, 2010 at 3:20 PM, Matt Benson wrote:
>> * WRT modules, what do you intend for the code remaining in the parent
>> project? I thought we might have a module each where we provide specialized
>> implementations of Invoker|Interce
On Fri, Jul 16, 2010 at 3:20 PM, Matt Benson wrote:
> * WRT modules, what do you intend for the code remaining in the parent
> project? I thought we might have a module each where we provide specialized
> implementations of Invoker|Interceptor|ObjectProvider...
>
The code is just sitting there
On Jul 14, 2010, at 9:21 PM, James Carman wrote:
> All,
>
> One of the biggest complaints I've received from folks about the proxy
> library is that it's not based on interfaces. The main class is the
> ProxyFactory class and it's a concrete class which implements all
> proxying logic using JDK
On Wed, Jul 14, 2010 at 11:52 PM, Matt Benson wrote:
> Easier to just follow a rule then debate about special cases, IMO. Do it!
Yeah, I'm one of the ones who is kind of a stickler on this list about
renaming packages, so I guess I should go ahead and do it. That way,
it stays consistent.
On Jul 14, 2010, at 10:45 PM, James Carman wrote:
On Wed, Jul 14, 2010 at 11:27 PM, Matt Benson
wrote:
This is in the neighborhood, but let me drop some stuff in there
tomorrow so
we can do a little CTR. :D
I am splitting proxy into multiple modules right now and I'll check it
into tha
On Wed, Jul 14, 2010 at 11:27 PM, Matt Benson wrote:
> This is in the neighborhood, but let me drop some stuff in there tomorrow so
> we can do a little CTR. :D
>
I am splitting proxy into multiple modules right now and I'll check it
into that branch so that folks can see what I have in mind as
On Jul 14, 2010, at 10:14 PM, James Carman wrote:
On Wed, Jul 14, 2010 at 11:12 PM, Matt Benson
wrote:
I would support [proxy] becoming a multi-module project; among
other things
we could selectively have a larger set of dependencies this way.
How would
you feel about the module that co
On Wed, Jul 14, 2010 at 11:12 PM, Matt Benson wrote:
> I would support [proxy] becoming a multi-module project; among other things
> we could selectively have a larger set of dependencies this way. How would
> you feel about the module that contains the recording functionality
> depending on [lan
On Jul 14, 2010, at 9:21 PM, James Carman wrote:
All,
One of the biggest complaints I've received from folks about the proxy
library is that it's not based on interfaces.
What is the typical basis of a complaint? I.e., what problem does
the abstract class cause?
The main class is the
P
All,
One of the biggest complaints I've received from folks about the proxy
library is that it's not based on interfaces. The main class is the
ProxyFactory class and it's a concrete class which implements all
proxying logic using JDK proxies. We did this for maintainability
(adding stuff to the
24 matches
Mail list logo
