; >
> > > see FTPHTTPClient.tunnelHandshake
> > >
> > > current code is:
> > >
> > > if (proxyUsername != null && proxyPassword != null) {
> > > final String auth = proxyUsername + ":" + proxyPassword;
> >
unnelHandshake
> >
> > current code is:
> >
> > if (proxyUsername != null && proxyPassword != null) {
> > final String auth = proxyUsername + ":" + proxyPassword;
> > final String header = "Proxy-
t; final String auth = proxyUsername + ":" + proxyPassword;
> final String header = "Proxy-Authorization: Basic " +
> Base64.getEncoder().encodeToString(auth.getBytes(charset));
> output.write(header.getBytes(charset));
> }
&
if (proxyUsername != null && proxyPassword != null) {
> final String auth = proxyUsername + ":" + proxyPassword;
> final String header = "Proxy-Authorization: Basic " +
> Base64.getEncoder().encodeToString(auth.getBytes(chars
see FTPHTTPClient.tunnelHandshake
current code is:
if (proxyUsername != null && proxyPassword != null) {
final String auth = proxyUsername + ":" + proxyPassword;
final String header = "Proxy-Authorization: Basic " +
Base64
ue, Apr 27, 2021, 07:16 sebb wrote:
>
> > I propose to move Proxy to dormant later this week unless anyone steps
> > up to fix the website etc.
> >
> > On Sat, 24 Apr 2021 at 18:13, sebb wrote:
> > >
> > > On Sat, 24 Apr 2021 at 00:35, Matt Benson wrot
Seems reasonable.
Gary
On Tue, Apr 27, 2021, 07:16 sebb wrote:
> I propose to move Proxy to dormant later this week unless anyone steps
> up to fix the website etc.
>
> On Sat, 24 Apr 2021 at 18:13, sebb wrote:
> >
> > On Sat, 24 Apr 2021 at 00:35, Matt Benson wro
linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 27 avr. 2021 à 13:17, sebb a écrit :
> I propose to move Proxy to dormant later this week unless anyone steps
> up to fix the website etc.
>
> On Sat, 24 Ap
I propose to move Proxy to dormant later this week unless anyone steps
up to fix the website etc.
On Sat, 24 Apr 2021 at 18:13, sebb wrote:
>
> On Sat, 24 Apr 2021 at 00:35, Matt Benson wrote:
> >
> > FWIW, my recollection is that proxy was ready for a 2.0 release which was
On Sat, 24 Apr 2021 at 00:35, Matt Benson wrote:
>
> FWIW, my recollection is that proxy was ready for a 2.0 release which was
> vetoed on the basis that the site didn't contain a migration how-to
> document. Oh well.
I don't think it was vetoed, but it looks like ther
FWIW, my recollection is that proxy was ready for a 2.0 release which was
vetoed on the basis that the site didn't contain a migration how-to
document. Oh well.
On Fri, Apr 23, 2021, 4:07 PM Gary Gregory wrote:
> Sounds reasonable to me.
>
> Gary
>
> On Thu, Apr 22, 202
Sounds reasonable to me.
Gary
On Thu, Apr 22, 2021, 16:09 sebb wrote:
> There has been no substantial development for several years, and only
> two open JIRA feature requests.
>
> The website is outdated, and needs regeneration.
>
> Is it worth spending any time on this component?
>
> I suspect
Le 23/04/2021 à 01:04, sebb a écrit :
> There has been no substantial development for several years, and only
> two open JIRA feature requests.
>
> The website is outdated, and needs regeneration.
>
> Is it worth spending any time on this component?
>
> I suspect it should go dormant.
+1
Emman
https://mvnrepository.com/artifact/org.apache.commons/commons-proxy/usages?p=1
[2]
https://github.com/FasterXML/jackson-databind/blob/c1465cea9f5a4dcb36ed7a531d080a74d01c74fb/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java#L184-L185
[3]
https://github.com/apache/sirona
There has been no substantial development for several years, and only
two open JIRA feature requests.
The website is outdated, and needs regeneration.
Is it worth spending any time on this component?
I suspect it should go dormant.
Sebb.
:48 AM, Pascal Schumacher <
> pascalschumac...@gmx.net>
> wrote:
>
> Hello everybody,
>>
>> the last release of Proxy is from 2008.
>>
>> I looks like attempts to release a 2.0 version were abandoned three and a
>> half year ago.
>
egory:
Sure, why not. In general, I'd rather leave components as they to give
folks the opportunity to contribute, but I won't stand in your way ;-)
Gary
On Sat, Oct 7, 2017 at 4:48 AM, Pascal Schumacher
wrote:
Hello everybody,
the last release of Proxy is from 2008.
I looks l
Sure, why not. In general, I'd rather leave components as they to give
folks the opportunity to contribute, but I won't stand in your way ;-)
Gary
On Sat, Oct 7, 2017 at 4:48 AM, Pascal Schumacher
wrote:
> Hello everybody,
>
> the last release of Proxy is from 2008.
>
&
Hello everybody,
the last release of Proxy is from 2008.
I looks like attempts to release a 2.0 version were abandoned three and
a half year ago.
Maybe it is time to move the component to dormant?
What do you think?
-Pascal
l , I think this can be accommodated
in core package for now if proxy developers[2] and PMC thinks different sub
modules its possible to create one for spring but ATM creating whole new
module seems difficult for maintenance to me.
Gary, Benedikt can put more insights here.
Regards,
Amey
Hi again Amey,
I reviewed commons proxy and found out it's last release is too old for
2008. Also it seems it's not popular; well known indexing sites like [1]
just has indexed it's core module rather than other modules like
javaassist and etc. (Did you mean I add my proposal
Thanks a lot! I was not aware about Apache Commons Proxy. However my
proposal is not about creating proxies , but, yes I think there is a
better place, thanks again.
On 5/24/2017 1:57 PM, Amey Jadiye wrote:
> +1 good idea! rather lang how about to move it to commons proxy[2] ? ATM it
> ha
+1 good idea! rather lang how about to move it to commons proxy[2] ? ATM it
have jdk, cglib, javassist, asm4 modules we can have one more for spring
as well. thoughts ?
Regards,
Amey
[2] https://commons.apache.org/proper/commons-proxy/
On Wed, May 24, 2017, 2:41 PM Yasser Zamani wrote:
>
It looks like it needs some TLC and a RM...
Gary
On Tue, Sep 16, 2014 at 1:02 PM, Romain Manni-Bucau
wrote:
> Hi guys
>
> any release planned for [proxy2]?
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibu
Hi guys
any release planned for [proxy2]?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
-
To unsubscribe
>> commons/proper/jelly/trunk/pom.xml
>> commons/proper/proxy/trunk/pom.xml
>>
>> Modified: commons/proper/jelly/trunk/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/jelly/trunk/pom.xml?rev=1619123&r1=1619122&r2=1619123&view=dif
On 21 August 2014 01:02, wrote:
> Author: sebb
> Date: Wed Aug 20 15:02:31 2014
> New Revision: 1619123
>
> URL: http://svn.apache.org/r1619123
> Log:
> Fix up URLs
>
> Modified:
> commons/proper/jelly/trunk/pom.xml
> commons/proper/proxy/trunk/pom.xml
&
Hi Matt,
Matt Benson wrote:
> I would like to release Commons Proxy 2.0.
>
> Commons Proxy 2.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/proxy/ (svn revision
> 4960)
>
> Maven artifacts are here:
>
https://repos
ks fine with Java 1.7 on Windows 8.1. Artifacts look good.
>>
>> The site does a good job in explaining basic principles, but it is
>> missing some concrete examples how proxy objects can be created and
>> used. But this is not a blocker for the release.
>>
>
On Mon, Apr 7, 2014 at 2:50 PM, Matt Benson wrote:
> I would like to release Commons Proxy 2.0.
>
> Commons Proxy 2.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/proxy/ (svn revision 4960)
>
> Maven artifacts are
So is this a +0, +1, abstain...?
Thanks,
Matt
On Wed, Apr 9, 2014 at 2:40 PM, Oliver Heger
wrote:
> Build works fine with Java 1.7 on Windows 8.1. Artifacts look good.
>
> The site does a good job in explaining basic principles, but it is
> missing some concrete examples how proxy
Build works fine with Java 1.7 on Windows 8.1. Artifacts look good.
The site does a good job in explaining basic principles, but it is
missing some concrete examples how proxy objects can be created and
used. But this is not a blocker for the release.
What I am missing is some specific
A suggestion for the site: The LHS menu area should provide navigation to
components and to the home page.
Gary
On Mon, Apr 7, 2014 at 3:50 PM, Matt Benson wrote:
> I would like to release Commons Proxy 2.0.
>
> Commons Proxy 2.0 RC1 is available for review here:
&g
oxy2-c
> > e:jar:tests:2.0: Failure to find
> > org.apache.commons:commons-proxy2-core:jar:2.0 in
> > http://repo.maven.apache.org/maven2 was cached in the local repository,
> > resolution will not be reattempted until the update interval of central
> has
> > elapsed
re forced -> [Help 1]
> [ERROR]
>
> How is one supposed to build this project? A BUILDING.txt would help.
>
> Gary
>
>
> On Mon, Apr 7, 2014 at 3:50 PM, Matt Benson wrote:
>
>> I would like to release Commons Proxy 2.0.
>>
>> Commons Proxy 2.0 RC1 is
2014 at 3:50 PM, Matt Benson wrote:
> I would like to release Commons Proxy 2.0.
>
> Commons Proxy 2.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/proxy/ (svn revision
> 4960)
>
> Maven artifacts are here:
>
> https://re
50 PM, "Matt Benson" wrote:
>
>> I would like to release Commons Proxy 2.0.
>>
>> Commons Proxy 2.0 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/proxy/ (svn revision
>> 4960)
>>
>> Maven artifacts
+1 non-binding vote...
Bill-
On Apr 7, 2014 1:50 PM, "Matt Benson" wrote:
> I would like to release Commons Proxy 2.0.
>
> Commons Proxy 2.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/proxy/ (svn revision
> 4960)
>
I would like to release Commons Proxy 2.0.
Commons Proxy 2.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/proxy/ (svn revision 4960)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1022
Details of
go for it
2014-03-27 15:58 GMT+01:00 Matt Benson :
> Probably so. My intent is to rename the asm stuff from ASM4* to ASM*.
>
> Matt
>
> On Thu, Mar 27, 2014 at 9:53 AM, sebb wrote:
> > There are newer versions of the following:
> >
> > cglib:cglib-nodep ... 2
Hi Matt,
it's great see some action in proxy. I'd like to have a look at the code,
but you know how it is... I can not promise, since I'll be pretty busy
until early may at work :-)
Best regards,
Benedikt
2014-03-27 5:29 GMT+01:00 Matt Benson :
> This is the notice that I
I think starting the classes should be @since tagged; that's standard
procedure in the javadoc world, as far as i know. Regarding what's
forgotten, I never worried about that and fixing it is easy.
On Thu, Mar 27, 2014 at 11:18 AM, sebb wrote:
> On 27 March 2014 15:47, Paul Benedict wrote:
> >
On 27 March 2014 15:47, Paul Benedict wrote:
> Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
> the class, there's no need for it to be on methods unless the methods are
> of another version. I think that's the standard javadoc way from Oracle
> anyway.
Yes.
But the on
Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
the class, there's no need for it to be on methods unless the methods are
of another version. I think that's the standard javadoc way from Oracle
anyway.
On Thu, Mar 27, 2014 at 10:35 AM, sebb wrote:
> Indeed.
>
> The poi
Indeed.
The point about not knowing where a missing annotation means it was
forgotten or whether it means ab initio may perhaps work with classes.
However once a class has an @since marker, there's no way of telling
whether its method and field @since markers are deliberately or
accidentally omit
+1. Due to the package change and fundamental shift from ProxyFactory
as abstract class to interface, arguably everything (or very nearly
so) is @since 2.0 anyway.
Matt
On Thu, Mar 27, 2014 at 10:22 AM, sebb wrote:
> Whilst removing the @author tags I noticed that there are 39 @since
> markers,
I don't know if removing @since 1.0 should be pursued. Coming from a
research perspective, the lack of them either indicates (1) since 1.0 or
(2) an omission. There's no way to know how someone would interpret their
omission so I would recommend keeping them so it's clear which methods
existed sinc
Whilst removing the @author tags I noticed that there are 39 @since
markers, all are @since 1.0.
I think we should remove these.
If not, then we need to add @since markers to identify what has been
added since.
-
To unsubscribe,
>
> Possibly your IDE did it for you.
>
>> On Thu, Mar 27, 2014 at 10:57 AM, Matt Benson wrote:
>>> James:
>>> As you are no doubt aware, the recommended practice in ASF Java code
>>> is to dispense with @author tags. You are, of course, listed in the
&
> As you are no doubt aware, the recommended practice in ASF Java code
>> is to dispense with @author tags. You are, of course, listed in the
>> Commons Proxy POM with the roles of admin/designer/developer. Do you
>> take issue with the removal of your @author
Probably so. My intent is to rename the asm stuff from ASM4* to ASM*.
Matt
On Thu, Mar 27, 2014 at 9:53 AM, sebb wrote:
> There are newer versions of the following:
>
> cglib:cglib-nodep ... 2.1_3 -> 3.1
>
> org.ow2.asm:asm-commons ...
are, of course, listed in the
> Commons Proxy POM with the roles of admin/designer/developer. Do you
> take issue with the removal of your @author tags from the source code?
>
> br,
> Matt
-
To unsubscribe, e-mail: dev-u
James:
As you are no doubt aware, the recommended practice in ASF Java code
is to dispense with @author tags. You are, of course, listed in the
Commons Proxy POM with the roles of admin/designer/developer. Do you
take issue with the removal of your @author tags from the source code?
br,
Matt
I'm always for living in the present ;) +1.
Gary
On Thu, Mar 27, 2014 at 10:53 AM, sebb wrote:
> There are newer versions of the following:
>
> cglib:cglib-nodep ... 2.1_3 -> 3.1
>
> org.ow2.asm:asm-commons . 4.2 -> 5.0.1
>
There are newer versions of the following:
cglib:cglib-nodep ... 2.1_3 -> 3.1
org.ow2.asm:asm-commons . 4.2 -> 5.0.1
org.ow2.asm:asm . 4.2 -> 5.0.1
jmock:jmock ..
FTR, I agree these should be removed, but out of common courtesy we should
probably seek James's acquiescence.
Matt
On Mar 27, 2014 9:43 AM, "sebb" wrote:
> Also just noticed that there are a lot of @author tags.
> These are deprecated, and should ideally be removed (the authors can
> be credite
Also just noticed that there are a lot of @author tags.
These are deprecated, and should ideally be removed (the authors can
be credited elsewhere).
One is yours, the rest are James Carman.
On 27 March 2014 14:13, sebb wrote:
> On 27 March 2014 13:16, Matt Benson wrote:
>> On Mar 27, 2014 6:43
On 27 March 2014 13:16, Matt Benson wrote:
> On Mar 27, 2014 6:43 AM, "sebb" wrote:
>>
>> On 27 March 2014 04:29, Matt Benson wrote:
>> > This is the notice that I intend to serve as release manager and begin
>> > cutting release candidates in the very near future after a very small
>> > amount
On Mar 27, 2014 6:43 AM, "sebb" wrote:
>
> On 27 March 2014 04:29, Matt Benson wrote:
> > This is the notice that I intend to serve as release manager and begin
> > cutting release candidates in the very near future after a very small
> > amount of remaining cleanup. Those of you who wish to form
On 27 March 2014 04:29, Matt Benson wrote:
> This is the notice that I intend to serve as release manager and begin
> cutting release candidates in the very near future after a very small
> amount of remaining cleanup. Those of you who wish to formulate and express
> opinions on the state of the c
This is the notice that I intend to serve as release manager and begin
cutting release candidates in the very near future after a very small
amount of remaining cleanup. Those of you who wish to formulate and express
opinions on the state of the codebase before the v2 API is set in stone
should pro
OH amazing news, thanks Matt!!!
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 19, 2014 at 3:49 PM, Matt Benson wrote:
> Bill Speirs and I were talking offline and we'd like to (finally) move
> forward with the next version of the [proxy] co
eviously deleted or renamed, but I did
> not have time to scan back to find out what happened.
>
> [Later]
>
> I have now found the rename sequence:
>
> $ svn log -v -l 2
http://svn.apache.org/repos/asf/commons/proper/proxy@1579340
> -------
to cause
> problems.
Was it a merge?
The commit added trunk as a copy of a branch.
I assume trunk must have been previously deleted or renamed, but I did
not have time to scan back to find out what happened.
[Later]
gt;>>
> >>> URL: http://svn.apache.org/r1579340
> >>> Log:
> >>> make 2.0 branch into trunk
> >>>
> >>> Added:
> >>> commons/proper/proxy/trunk/
> >>> - copied from r1579339,
> commons/proper/proxy/b
PM, sebb wrote:
>> On 19 March 2014 18:30, wrote:
>>> Author: mbenson
>>> Date: Wed Mar 19 18:30:46 2014
>>> New Revision: 1579340
>>>
>>> URL: http://svn.apache.org/r1579340
>>> Log:
>>> make 2.0 branch into trunk
>>>
>
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=28381&projectId=100
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed 19 Mar 2014 23:20:51 +
Finished at: Wed 19 Mar 2014 23:21:03 +
Total time: 12s
Build Trigger: Schedul
t;
>> URL: http://svn.apache.org/r1579340
>> Log:
>> make 2.0 branch into trunk
>>
>> Added:
>> commons/proper/proxy/trunk/
>> - copied from r1579339, commons/proper/proxy/branches/version-2.0-work/
>> Removed:
>> commons/proper/pr
On 19 March 2014 18:30, wrote:
> Author: mbenson
> Date: Wed Mar 19 18:30:46 2014
> New Revision: 1579340
>
> URL: http://svn.apache.org/r1579340
> Log:
> make 2.0 branch into trunk
>
> Added:
> commons/proper/proxy/trunk/
> - copied from r1579339, comm
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=28380&projectId=100
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed 19 Mar 2014 19:28:31 +
Finished at: Wed 19 Mar 2014 19:28:47 +
Total time: 16s
Build Trigger: Schedule
Good news to see some action there again.
Gary
Original message
From: Matt Benson
Date:03/19/2014 10:49 (GMT-05:00)
To: dev@commons.apache.org
Subject: [proxy] toward a 2.0 release
Bill Speirs and I were talking offline and we'd like to (finally) move
forward wit
Bill Speirs and I were talking offline and we'd like to (finally) move
forward with the next version of the [proxy] component. We hope to add
another feature or so, polish up the website and release in the coming
weeks. Please take this email as the prelude to the official release
proposa
Online report :
http://localhost:8080/continuum/buildResult.action?buildId=27603&projectId=100
Build statistics:
State: Failed
Previous State: Ok
Started at: Tue 7 Jan 2014 12:51:54 +
Finished at: Tue 7 Jan 2014 12:52:09 +
Total time: 15s
Build Trigger: Forced
Build Number:
lly same applies for Unsafe which is used by all
> frameworks. I don't say we should drop spi to use it, just we should
> support it as a base when nothing is provided. IMO this would really
> simplify the setup of [proxy]
> Romain Manni-Bucau
> Twitter: @rmannibucau
>
Your initial statement is right however I don't get why we shouldn't
do it. basically same applies for Unsafe which is used by all
frameworks. I don't say we should drop spi to use it, just we should
support it as a base when nothing is provided. IMO this would really
simplify the
t;
> This could be great for [proxy] to support it in main module and avoid
> the need to add any bytecode library from the user perspective no?
However, it looks like this is part of the intermal workings of JDK8.
Unless there is a public API, it would tie proxy to working with one
particular J
Hello guys,
Maybe too early and I'm pretty I'll not get time to work on it in the
following months but saw yesterday jdk8 contains asm repackaged:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b
This could be great for [proxy] to support it in main module and avoid
the need
On 14/10/2013 17:59, sebb wrote:
>> Added:
>> commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2/proxy/CglibProxyHandler.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2/proxy/CglibProxyHandler.ja
On 14 October 2013 11:50, wrote:
> Author: markt
> Date: Mon Oct 14 10:50:28 2013
> New Revision: 1531846
>
> URL: http://svn.apache.org/r1531846
> Log:
> Add CGLib proxy implementation and test.
>
> Added:
>
> commons/proper/pool/trunk/src/main/ja
On 10/14/13 3:50 AM, ma...@apache.org wrote:
> Author: markt
> Date: Mon Oct 14 10:50:28 2013
> New Revision: 1531846
>
> URL: http://svn.apache.org/r1531846
> Log:
> Add CGLib proxy implementation and test.
>
> Added:
>
> commons/proper/pool/trunk/src/main/ja
generate using ASM (which do the getInstance() internally as well ->
> ThreadLocal, Map lookup, etc) take 30ms on my notebook.
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Romain Manni-Bucau
> > To: Commons Developers List
> > Cc
k.
LieGrue,
strub
- Original Message -
> From: Romain Manni-Bucau
> To: Commons Developers List
> Cc:
> Sent: Thursday, 1 August 2013, 17:15
> Subject: Re: [proxy] and impl
>
> hehe, do you have figures?
>
> when JIT did its work reflection is almost free. You c
vider, Foo.class);
> Foo javassistFoo = javassist.createDelegatorProxy(provider,
> Foo.class);
>
> final Foo[] foos = new Foo[]{jdkFoo, cglibFoo, javassistFoo};
>
> benchmark(foos, 10);
>
>
> }
> }
>
> On Thu, Aug 1, 2013 at 11:1
(provider, Foo.class);
final Foo[] foos = new Foo[]{jdkFoo, cglibFoo, javassistFoo};
benchmark(foos, 10);
}
}
On Thu, Aug 1, 2013 at 11:15 AM, Romain Manni-Bucau
wrote:
> hehe, do you have figures?
>
> when JIT did its work reflection is almost free. You
hehe, do you have figures?
when JIT did its work reflection is almost free. You can update the asm
proxy factory to handle 3 implementations but it is not worth it IMO
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/
om/rmannibucau>*
> >> > > *Blog: **http://rmannibucau.wordpress.com/*<
> >> > http://rmannibucau.wordpress.com/>
> >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> > > *Github: https://github.com/rmannibucau*
> >> >
t;> > >
>> > >
>> > >
>> > > 2013/8/1 Matt Benson
>> > >
>> > >> The behavior of proxies is specified by Invokers, ObjectProviders, and
>> > >> Interceptors. Each ProxyFactory implementation bridges from these
>> >
eptors. Each ProxyFactory implementation bridges from these
> > >> interfaces to the most appropriate mechanism specific to the target
> > >> technology. In the case of ASM, I would think that would be direct
> calls
> > >> against the proxy interface imple
r of proxies is specified by Invokers, ObjectProviders, and
> >> Interceptors. Each ProxyFactory implementation bridges from these
> >> interfaces to the most appropriate mechanism specific to the target
> >> technology. In the case of ASM, I would think that would be direct call
o the target
>> technology. In the case of ASM, I would think that would be direct calls
>> against the proxy interface implementations themselves.
>>
>> Matt
>> On Aug 1, 2013 9:21 AM, "Romain Manni-Bucau"
>> wrote:
>>
>>> a sed
ory implementation bridges from these
> interfaces to the most appropriate mechanism specific to the target
> technology. In the case of ASM, I would think that would be direct calls
> against the proxy interface implementations themselves.
>
> Matt
> On Aug 1, 2013 9:21 AM, "
The behavior of proxies is specified by Invokers, ObjectProviders, and
Interceptors. Each ProxyFactory implementation bridges from these
interfaces to the most appropriate mechanism specific to the target
technology. In the case of ASM, I would think that would be direct calls
against the proxy
au>*
>> > *Blog: **http://rmannibucau.wordpress.com/*<
>> > http://rmannibucau.wordpress.com/>
>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> > *Github: https://github.com/rmannibucau*
>> >
>> >
>> >
>> > 2013/8/1 James Carman
es Carman
> >
> > > You mean all the InvocationHandler classes in JdkProxy? I guess we
> > > could break those out into top-level classes, but then you'd have
> > > multiple implementations on your classpath if you made a dependency on
> > >
*Github: https://github.com/rmannibucau*
>
>
>
> 2013/8/1 James Carman
>
> > You mean all the InvocationHandler classes in JdkProxy? I guess we
> > could break those out into top-level classes, but then you'd have
> > multiple implementations on your cla
/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/8/1 James Carman
> You mean all the InvocationHandler classes in JdkProxy? I guess we
> could break those out into top-level classes, but then you'd have
> multiple implementations on your classpath if you made a dependency o
You mean all the InvocationHandler classes in JdkProxy? I guess we
could break those out into top-level classes, but then you'd have
multiple implementations on your classpath if you made a dependency on
commons-proxy-jdk. We could move those to "core" I guess.
On Thu, Aug 1,
Ok for all excepted last point (i was not clear i think). The ProxyFactory
impl using jdk proxy uses Invocationhandler like the asm implementation so
it would be great to be able to share the handler classes between both impl.
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.
s
like Mockito/EasyMock. Basically, you can "train" a proxy to do what
you want in certain situations.
> 2) in ProxyFactory methods have this kind of signature
>
> T createDelegatorProxy( ClassLoader classLoader, ObjectProvider
> delegateProvider,
>
mannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/7/31 James Carman
> I know. I mean can we get a patch against the 2.x branch.
>
>
> On Wed, Jul 31, 2013 at 3:44 PM, Matt Benson wrote:
> > Since [proxy] is
1 - 100 of 1278 matches
Mail list logo
